Closed Bug 1067470 Opened 10 years ago Closed 9 years ago

Firefox window is not repainted sometimes after switching tab (seems to be caused by OMTC; fps counter doesn't update / Present stops working)

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
33 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED DUPLICATE of bug 1157784
Tracking Flags:
Tracking Status
e10s ? ---
firefox34 --- ?
firefox35 - wontfix
firefox36 + wontfix
firefox37 + wontfix
firefox38 + wontfix
firefox39 - verified
firefox38.0.5 --- verified
firefox40 - verified
firefox41 --- verified
firefox-esr31 --- unaffected
firefox-esr38 --- verified

People

(Reporter: mtanalin, Assigned: jrmuizel)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [gfx-noted])

User Story

Summary:
Seems to be caused by OMTC

Attachments

(8 files)

Screenshot of bug affecting tab-bar
41.21 KB, image/jpeg
Details
Parts of bugzilla-tab still being rendered after switching to mibbit-tab.
259.72 KB, image/jpeg
Details
Rendering bug on tabs change
344.01 KB, image/png
Details
"mozregression --bits 32 --good-release 32 --bad-release 33" results
37.94 KB, image/png
Details
try1 - L406.txt
1.23 KB, text/plain
Details
try2 - L517.txt
1.68 KB, text/plain
Details
tab
6.57 KB, image/png
Details
Firefox_painting_error.png
21.88 KB, image/png
Details 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20140911191954

Steps to reproduce:

Sometimes, after switching from one tab to another one in Firefox 33 beta, Firefox looks like being frozen/hanging.


Actual results:

Sometimes, after switching from one tab to another one, Firefox looks like being frozen/hanging. But after switching to another _application_ and then switching back to Firefox window, it works fine, and tab is actually already switched to the one that I intended to switch before Firefox has been frozen.

Note that this does not occur always, just sometimes, so it's hard to determine what exact 33.x build has introduced the bug.

FWIW, I use Windows 7 Home Premium as OS.


Expected results:

Firefox should repaint its window correctly when switching tabs — without looking hanging — i.e. Firefox should work just as Firefox 32 and earlier versions before Firefox 33.
Confirming bug.

Hardware acceleration: disabled
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Status: UNCONFIRMED → NEW
Ever confirmed: true
Some additional observations so far:

* Window is also (besides switching-to-another-application trick) repainted if:

	* to click a button on a Firefox toolbar;
	* a tab tooltip has been shown.

* Looks like content of target tab (i.e. the tab that user has switched to, but does not see it) is functional (though invisible):

e.g. links on the tab can be hovered by mouse since moving the mouse leads to changing mouse cursor to pointer on some areas (and those areas do not correspond to where are links in the previous tab's contents), and clicking such links seems to lead to loading corresponding URLs [though they are invisible too], etc.).
Severity: normal → critical
Is it possible to find a regression range for this bug?

https://quality.mozilla.org/docs/bugzilla/guide-to-triaging-bugs-for-firefox/finding-a-regression-window/

jrmuizel - based on the description of the bug, do you know where or to whom we should direct this bug? It sounds like Graphics...
Flags: needinfo?(jmuizelaar)
Keywords: regression, regressionwindow-wanted
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #3)
> Is it possible to find a regression range for this bug?

That's unlikely given that the bug appears quite randomly and not very frequently (a few times per day).

What I can say quite certainly is that the bug is introduced in Firefox 33 (the bug symptoms didn't occur in Firefox 32), so the first step in resolving the bug is probably to find all fixed-in-Firefox-33 bugs that are related to graphics/rendering.
Didn't encounter the bug several days (approx. since Beta 6 or 7), so marking it as WFM for now. Will reopen if I will encounter the bug again.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Still seeing the bug on Aurora, reopening.

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Observed the bug again too in the current Firefox 33 Beta 8 (20140929180120), unfortunately.
Same with Firefox 33 stable.
This bug can affect both content and chrome. Screenshot shows the tab-bar not rendering/updating properly after switching tab.
Tried a new clean profile with the latest Firefox 34 beta, same result.

This bug literally ruins user experience and Firefox as a usable and competitive product. Sadly.

Downgraded to Firefox 31 ESR (would use Fx 32 ESR as a pre-bug major version if it existed) to prevent encountering the bug at least for several months until a next ESR release with the hope that the bug will be fixed by that time.

By the way, there were repainting issues in Firefox 33 (Fennec) for ARM on a tablet (e.g. a checkbox state did repaint only after scrolling page to a position where checkbox is out of visible area of browser and then scrolling back to see the checkbox with new state applied; also bottom parts of some pages were permanently pixelated as immediately after scrolling), and they were also resolved by downgrading to 31 ESR. The reason is probably the same as with this bug — a serious graphics-wise change in Gecko as of 33.x.
Severity: critical → blocker
Version: 33 Branch → 34 Branch
(In reply to Marat Tanalin | tanalin.com from comment #10)
> Tried a new clean profile with the latest Firefox 34 beta, same result.

Clean profile as in without extensions or plugins enabled?
(In reply to comment #11)
> Clean profile as in without extensions or plugins enabled?

Totally clean profile with no extensions. As for plugins, they are not a part of any profile, and the only two enabled ones were Adobe Acrobat 11.0.9.29 (disabled in my main profile by the way) and Shockwave Flash 15.0.0.223.
Marat, could to test with OMTC disabled?

I believe all you need to do is set "layers.offmainthreadcomposition.enabled" to false in about:config.
Flags: needinfo?(mtanalin)
(In reply to comment #13)
> Marat, could to test with OMTC disabled?

OK, switched to latest Firefox Beta again and set `layers.offmainthreadcomposition.enabled` to `false`, will see if it helps (at least several extra days are needed for more or less representative statistics due to spontaneous nature of the bug). Thanks.

P.S. Tried to disable the parameter in Firefox 33 for Android too to overcome its repainting issues, but then _all_ pages (including `about:config` itself; the only exception I've seen was `about:home`) were rendered blank (though thumbnails to the left of the screen seemed to render correctly), and I was't even be able to switch the parameter back to `true`. So at least for Android, it doesn't help (and even quite the contrary). Switched back to 31 ESR again as for Android version of Firefox.
(In reply to Marat Tanalin | tanalin.com from comment #14)
> (In reply to comment #13)
> > Marat, could to test with OMTC disabled?
> 
> OK, switched to latest Firefox Beta again and set
> `layers.offmainthreadcomposition.enabled` to `false`, will see if it helps
> (at least several extra days are needed for more or less representative
> statistics due to spontaneous nature of the bug). Thanks.

Yeah, I know. I'm trying to figure out what's causing this, and since you mentioned this started with v33 I figured the release notes for v33 could be a good start. OMTC was enabled by default on Windows in v33, and if we can determine if this is the root of the bug, we might have a chance of helping some dev fix this. :)
Finding a regression window for this is almost impossible. I thought flash or some other plugin could be to blame, or perhaps noscript, but since you're experiencing the bug without any extensions that can't be it (I think?).
 
> P.S. Tried to disable the parameter in Firefox 33 for Android too to
> overcome its repainting issues, but then _all_ pages (including
> `about:config` itself; the only exception I've seen was `about:home`) were
> rendered blank (though thumbnails to the left of the screen seemed to render
> correctly), and I was't even be able to switch the parameter back to `true`.
> So at least for Android, it doesn't help (and even quite the contrary).
> Switched back to 31 ESR again as for Android version of Firefox.

I don't believe you mentioned having (similar?) problems on Android before? It might be a good idea if you filed another bug for that.
I wonder if bug 875209 is related.
Status: REOPENED → NEW
See Also: → 875209
Flags: needinfo?(mtanalin)
Flags: needinfo?(jmuizelaar)
Doh, one too many.

Re-adding NEEDINFO: jmuizelaar@mozilla.com.

Jeff, please see https://bugzilla.mozilla.org/show_bug.cgi?id=1067470#c3 for the original NEEDINFO request.
Flags: needinfo?(jmuizelaar)
Ignore the smudged text, that's not due to the bug.
(In reply to Johan C from comment #15)
> OMTC was enabled by default on Windows in v33, and if we can
> determine if this is the root of the bug

Well, during 10 days of using Firefox with OMTC disabled, I didn't encounter the bug at all. Once I've enabled OMTC as an experiment, I did encounter the bug again the same day. So it's quite probable that OMTC is the reason of the bug. BTW, I'm now using Firefox 35 Beta instead of Firefox 34 Beta.

What I've noticed is that, with OMTC disabled, new tabs are created without animation, and content area of the new tab is rendered with a delay (probably equal to duration of the invisible tab animation) while, with OMTC enabled, new tabs are created with animation and content area of the new tab is rendered immediately, without a delay. Such delay creates some effect of browser's permanent lower-responsiveness, so disabling OMTC is not quite painless as for user experience (even aside from losing potential advantages of the OMTC itself).

By the way, it seems that Firefox 35 Beta for Android has fixed the two bugs that I've mentioned in the comment 10 (checkboxes are now repainted correctly, and there is no permanent pixelation of bottom part of webpages anymore).
> with OMTC disabled, new tabs are created without
> animation, and content area of the new tab is rendered with a delay

Looks like that once I've written about the tab animation issue taking place when OMTC is disabled, tab animations have suddenly started to work, and delay has gone. Maybe switching the `layers.offmainthreadcomposition.enabled` pref from `false` to `true` and back has somehow resulted in this "self-fixing", or this is a consequence of updating Fx 35 Beta 1 to Beta 2 occured yesterday, or this is yet another bug that appears and disappears spontaneously.
Component: Untriaged → Graphics
Product: Firefox → Core
Version: 34 Branch → 33 Branch
Confirmed also here, on both Nightly: x86 and x64,  STR is quite easy, open few tabs and start switch between them, after some short time You can see graphics glitches on tabs as mentioned in comment 0 plus site painting problems, kind of artifacts. OMTC disabled, HWA enabled.
Yeah, I don't think there's much that I can say about this with out a regression window. 

If people can run this program during the black screen and post the crash report from about:crashes

http://people.mozilla.org/~jmuizelaar/crash-firefox.exe
Flags: needinfo?(jmuizelaar)
I started using HWA on my main firefox-profile and don't remember seeing the bug since. However I'm running a bunch of other firefox-profiles less frequently where HWA is disabled and it looks like the bug still exists. But seeing as semtex reports in comment #22 that he's seeing the bug with HWA enabled I don't know if this is relevant.


(In reply to Jeff Muizelaar [:jrmuizel] from comment #23)
> If people can run this program during the black screen and post the crash
> report from about:crashes
> 
> http://people.mozilla.org/~jmuizelaar/crash-firefox.exe
With HWA disabled and e10 enabled on Nightly 37.0a1 (pre https://hg.mozilla.org/mozilla-central/rev/7b33ee7fd162):
The bug appeared in a "Warning: Unresponsive Script"-popup. Crashed Nightly with crash-firefox.exe
Crash report: https://crash-stats.mozilla.com/report/index/342d7476-bc0e-443f-a101-fce852141221


(In reply to Jeff Muizelaar [:jrmuizel] from comment #23)
> Yeah, I don't think there's much that I can say about this with out a regression window.
While not exactly a regression window, it looks like the bug appeared in Firefox 33.


Please let me know if I can provide additional information to the crash report.
Flags: needinfo?(jmuizelaar)
(In reply to Johan C from comment #24)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #23)
> > If people can run this program during the black screen and post the crash
> > report from about:crashes
> > 
> > http://people.mozilla.org/~jmuizelaar/crash-firefox.exe
> With HWA disabled and e10 enabled on Nightly 37.0a1 (pre
> https://hg.mozilla.org/mozilla-central/rev/7b33ee7fd162):
> The bug appeared in a "Warning: Unresponsive Script"-popup. Crashed Nightly
> with crash-firefox.exe
> Crash report:
> https://crash-stats.mozilla.com/report/index/342d7476-bc0e-443f-a101-
> fce852141221
> 

How are you disabling HWA? That crash report suggests that HWA is not disabled.
Flags: needinfo?(jmuizelaar) → needinfo?(johan.charlez)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #25)
> How are you disabling HWA? That crash report suggests that HWA is not
> disabled.

My mistake, HWA is enabled. I must have enabled it to debug something, it's usually not enabled on Nightly.
Flags: needinfo?(johan.charlez)
After auto-updating from Firefox 35 beta to Firefox 36 beta, YouTube.com has started to crash my Firefox almost always when trying to play any video if `layers.offmainthreadcomposition.enabled` is `false` (verified with a new clean profile -- it does not crash if the pref is `true` and does crash if it's `false`).

So disabling OMTC is not a viable solution anymore, but with OMTC enabled I will almost certainly encounter the repainting bug again (with OMTC disabled, I didn never encounter the bug AT ALL).

FWIW, other video hostings (both Flash-based like rutube.ru and HTML5-Video-based like vimeo.com) do not cause Firefox crashes like YouTube does.
(In reply to Marat Tanalin | tanalin.com from comment #28)
> So disabling OMTC is not a viable solution anymore, but with OMTC enabled I
> will almost certainly encounter the repainting bug again (with OMTC
> disabled, I didn never encounter the bug AT ALL).

Sorry, that's my bad, I didn't mean for you to use it as a workaround. The idea was to see if you still encountered the bug with OMTC disabled.
(In reply to Johan C from comment #29)
That's clear, but until the bug is fixed, disabling OMTC _was_ a good workaround anyway. And unfortunately it isn't anymore -- something in Fx 36 (added/changed compared with Fx 35) is probably relying on OMTC enabled and does not take into account that it can be disabled.

A probable YouTube-related candidate reason of crashes according to Firefox 36 Beta Notes (https://www.mozilla.org/en-US/firefox/36.0beta/releasenotes/ ) is:

"Implemented a subset of the Media Source Extensions (MSE) API to allow native HTML5 playback on YouTube".

But setting `media.mediasource.enabled`, `media.mediasource.mp4.enabled`, and `media.mediasource.youtubeonly` to `false` does not fix the crashing issue.
(In reply to Marat Tanalin | tanalin.com from comment #30)
> That's clear, but until the bug is fixed, disabling OMTC _was_ a good
> workaround anyway. And unfortunately it isn't anymore -- something in Fx 36
> (added/changed compared with Fx 35) is probably relying on OMTC enabled and
> does not take into account that it can be disabled.

Have you tried with HWA (hardware acceleration) on and off?

HWA has diminished the issue for me.
See Also: 1064864 → 1108499, 1110696
(In reply to Johan C from comment #31)
Looks like disabling hardware acceleration solves the YouTube-crash issue, thanks. But then Firefox-UI fonts get somewhat blurry.
Filed bug 1123081 about YouTube-related crashing of Firefox 36 beta.
This seems like excessive duping around to me *shrug*. I didn't see this bug until around the time bug 1107297 landed on Nightly, about a month ago now. I can't really confirm that bug as the cause since this happens very rarely for me, but I never saw this before Firefox 37.
Sorry for this, but the same issues need to be duped to only one bug, so it won't be too much havoc.

I still see it sometimes on Nightly 38, so definitely it's still not fixed yet
and before I saw this issue on Nightly 34.


[Tracking Requested - why for this release]: per bug #1108499 comment 33

needinfo?: per per bug #1108499 comment 31
I still haven't been able to reproduce this, does anyone have more reliable STR than just trying to switch tabs for half an hour :)?
Flags: needinfo?(bas)
Im pretty sure the cause is OMTC. This bug seems to be the same. https://bugzilla.mozilla.org/show_bug.cgi?id=1103431 It has link to mozillazine forums where it seems people confirm that switching OMTC off stops the bug from occurring.
(In reply to kalviskajaks from comment #43)
> Im pretty sure the cause is OMTC. This bug seems to be the same.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1103431 It has link to
> mozillazine forums where it seems people confirm that switching OMTC off
> stops the bug from occurring.

Nope, I don't use OMTC and I'm still able to reproduce this bug without problem....
Are you sure you have "layers.offmainthreadcomposition.enabled" set to false in about:config ?
See Also: → 1102681
(In reply to kalviskajaks from comment #45)
> Are you sure you have "layers.offmainthreadcomposition.enabled" set to false
> in about:config ?

You Was right, this entry was set to "true", this is very strange, since main OMTC option is flipped to off, this still influence my browser, after changing to "false" problem was gone but browser start crashing on YT movies, there is another bug with this problem. So, we have workaround....
It clearly sucks when the browser gets into this state. However, as this is an intermittent issue that is difficult to reliably reproduce, I'm not going to track. We should fix this issue and should determine whether we can uplift a fix once we have one.
status-firefox34: affected → wontfix
status-firefox35: affected → wontfix
tracking-firefox35: ? → -
tracking-firefox36: ? → -
tracking-firefox37: ? → -
tracking-firefox38: ? → -
(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #48)
> It clearly sucks when the browser gets into this state. However, as this is
> an intermittent issue that is difficult to reliably reproduce, I'm not going
> to track. We should fix this issue and should determine whether we can
> uplift a fix once we have one.

As an unfortunate result of all the duplicating that happened, the tracking flags from bug 1108499 were lost. Can they not carry over? See bug 1108499 comment 33.
Flags: needinfo?(lmandel)
Thank you for highlighting bug 1108499 as a dup. The description in that bug sounds much more severe than the description in this bug. Given that there seems to be a larger issue here, I will revert my decision in comment 48 and track this bug.

Milan - Not sure how we can make progress here as Bas is unable to reproduce. ni simply to flag this for you. (I don't expect a miracle answer.)
tracking-firefox36: - → +
tracking-firefox37: - → +
tracking-firefox38: - → +
Flags: needinfo?(lmandel) → needinfo?(milan)
(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #50)
> Thank you for highlighting bug 1108499 as a dup. The description in that bug
> sounds much more severe than the description in this bug.

For what it's worth: for me, the bug's symptom is exactly what I've described: Firefox window is just not repainted after switching (or closing) a tab; there is no any mixing of content of different tabs for me.
Whiteboard: [if you can reproduce it often - see comment 23]
Yeah, not sure where to take this - except to add that I've actually seen the "no repaint" (white, not black) on OS X! - 36 beta.  Nothing I could do would repaint the part of the chrome between the tab and the window border (including minimizing and re-opening the window.)  Leaving NI, maybe I can reproduce it (this was on the Air, Yosemite.)
Never seen it on OS X myself, but had it on two Windows machines, one with AMD, one with Intel graphics. Another possibly related graphical glitch is that when closing other than the last, the last tab would stay visibly floating and not slide to fill the empty space. I've disabled OMTC earlier today while leaving HWA enabled, and haven't seen it so far.
Milan, Clint has been working to get a company to help us on graphic tests. Maybe they can reproduce it.
Anyway, with OMTC unsupported, we need to come up with a workaround.
Flags: needinfo?(ctalbert)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #23)
> Yeah, I don't think there's much that I can say about this with out a
> regression window. 
> 
> If people can run this program during the black screen and post the crash
> report from about:crashes
> 
> http://people.mozilla.org/~jmuizelaar/crash-firefox.exe

I manged to ctach one i think, not sure if useful.https://crash-stats.mozilla.com/report/index/87243696-18b2-46b8-8085-56f252150129
(In reply to kalviskajaks from comment #55)
> I manged to ctach one i think, not sure if
> useful.https://crash-stats.mozilla.com/report/index/87243696-18b2-46b8-8085-
> 56f252150129

Unfortunately it's misleading tail.
I had the same crash signature when I force crash Nightly when we had bug #1064864 (some more info in dupe bug #1060726)
See Also: → 1064864
(In reply to Virtual_ManPL [:Virtual] from comment #56)
> (In reply to kalviskajaks from comment #55)
> > I manged to ctach one i think, not sure if
> > useful.https://crash-stats.mozilla.com/report/index/87243696-18b2-46b8-8085-
> > 56f252150129
> 
> Unfortunately it's misleading tail.
> I had the same crash signature when I force crash Nightly when we had bug
> #1064864 (some more info in dupe bug #1060726)

Would running the profiler in this https://bugzilla.mozilla.org/show_bug.cgi?id=1060726#c2 comment be useful? And if yes, do i need to force the crash in comment 23 too or just run the profiler?
(In reply to Virtual_ManPL [:Virtual] from comment #56)
> (In reply to kalviskajaks from comment #55)
> > I manged to ctach one i think, not sure if
> > useful.https://crash-stats.mozilla.com/report/index/87243696-18b2-46b8-8085-
> > 56f252150129
> 
> Unfortunately it's misleading tail.
> I had the same crash signature when I force crash Nightly when we had bug
> #1064864 (some more info in dupe bug #1060726)

I got a profile while the bug was hapening. How do i share it? The share button didnt work because it was bigger than 9 mb.
Benoit, can you take a look at the profile from comment 59?
Flags: needinfo?(milan) → needinfo?(bgirard)
This is a correctness bug. I'm not sure what we expect to see from a performance profile. But I looked anyways and I don't see any samples preparing D3D11 commands, just the present call. Probably means we're not compositing a full frame.

We've already found the root of the problem here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1108499#c31

You can see my try run to see the patch I did which disables the partial present.

Looks like we landed a fix for it rencently in bug 1117925. Can someone reproduce this using a nightly build since the 23th?
Flags: needinfo?(bgirard)
(In reply to Benoit Girard (:BenWa) from comment #61)
> This is a correctness bug. I'm not sure what we expect to see from a
> performance profile. But I looked anyways and I don't see any samples
> preparing D3D11 commands, just the present call. Probably means we're not
> compositing a full frame.
> 
> We've already found the root of the problem here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1108499#c31
> 
> You can see my try run to see the patch I did which disables the partial
> present.
> 
> Looks like we landed a fix for it rencently in bug 1117925. Can someone
> reproduce this using a nightly build since the 23th?

-_- yes 2 times already comment 55 and comment 58-59 is me running an updated nightly build on the 29th...
Ahh sorry! Can you try this build then? It did the trick in bug 1117925, it did the job there. I had to retrigger it since it expired: https://treeherder.mozilla.org/#/jobs?repo=try&revision=38982cccce8f

Once it's ready I'll post the link. Just download it, unzip, close your Firefox session, run and reproduce the problem.
Flags: needinfo?(bgirard)
Sledru, without clear steps on how to repro it, I can't get the offsite team a way to test it.  I can have them swap tabs a couple of times, but it's not clear that would really do the trick. :-(
Flags: needinfo?(ctalbert)
(In reply to Benoit Girard (:BenWa) from comment #63)
> Ahh sorry! Can you try this build then? It did the trick in bug 1117925, it
> did the job there. I had to retrigger it since it expired:
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=38982cccce8f
> 
> Once it's ready I'll post the link. Just download it, unzip, close your
> Firefox session, run and reproduce the problem.

Was there supposed to be a download link somewhere on that page? If yes i cant find it.
And its still happening http://i.imgur.com/eY861MQ.png only the middle part should have been there, the things on the sides are bleeding in from the reddit tab...

And it happened again while i was uploading the picture.. All this with the latest nightly! It definitely isn't fixed. I cant take it anymore..
one more picture, it even happens on the new tab page. http://i.imgur.com/OFT2SLv.png
Severity: major → critical
(In reply to kalviskajaks from comment #65)
> Was there supposed to be a download link somewhere on that page? If yes i
> cant find it.

It's kinda hidden, if you don't know where to look ;)

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/b56girard@gmail.com-38982cccce8f/try-win32/
Yes, please use this one:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/b56girard@gmail.com-38982cccce8f/try-win32/firefox-37.0a1.en-US.win32.zip

Make sure to close firefox to unlock your profile otherwise youll get either an error message or it will just open a window from your release version.
Flags: needinfo?(bgirard) → needinfo?(kalviskajaks)
Could not trigger this bug with the linked build. Instead i got the tab freezes again like in bug 1103431 which did not happen in the regular nightly anymore.
Flags: needinfo?(kalviskajaks)
I guess it is not going to be fixed for 36.
status-firefox36: affected → wontfix
Milan, BenWa - This bug has been kicking around for a while. We don't seem to have good ideas on how to get additional information for you. Do you have any ideas on how to make progress?
Flags: needinfo?(milan)
Flags: needinfo?(bgirard)
Bas, the problem is caused by the code here:
http://mxr.mozilla.org/mozilla-central/source/gfx/layers/composite/LayerManagerComposite.cpp#285

If we don't have a fix in the pipeline we should disable this code. This will probably stop us from doing the partial present.
Flags: needinfo?(bas)
Note: There's a *tiny* chance that this is caused by bug 1109314.
See Also: → 1109314
Flags: needinfo?(milan)
To Mozilla developers:

guys, given that there are _manual_ user actions that ALWAYS force window repainting (e.g. pressing a toolbar button or appearing a tooltip of a content link or of a GUI element like tab title), why not just add an equivalent _automatic_ repainting action to Firefox code itself (related to switching tabs) as a temporary fix?

In other words, it should be enough to just repaint window forcedly every time a tab is switched.

Then, when/if the actual reason of the bug will be found and fixed, this temporary workaround fix could be removed. But for now, Firefox users would not suffer anymore, and Firefox would not keep losing its users (by the way, market share of Firefox in Russia is now just 7.5%, and that's a real shame [1]).

Thanks.

[1] https://www.liveinternet.ru/stat/ru/browsers.html?period=month;lang=en
Blocks: 1130362
Again(In reply to Marat Tanalin | tanalin.com from comment #75)
> To Mozilla developers:
> 
> guys, given that there are _manual_ user actions that ALWAYS force window
> repainting (e.g. pressing a toolbar button or appearing a tooltip of a
> content link or of a GUI element like tab title), why not just add an
> equivalent _automatic_ repainting action to Firefox code itself (related to
> switching tabs) as a temporary fix?

Unfortunately, this isn't really practical or possible. From a graphics point of view there's not really anything special about switching tabs.

The best thing for anyone who can reproduce this is to see if they can get a regression window using the process described here:
http://mozilla.github.io/mozregression/

That will go a long way in determining the cause of this problem.
Assignee: nobody → jmuizelaar
Summary: Firefox window is not repainted sometimes after switching tab → Firefox window is not repainted sometimes after switching tab seems to be caused by OMTC
(In reply to Jeff Muizelaar [:jrmuizel] from comment #76)
> Again(In reply to Marat Tanalin | tanalin.com from comment #75)

Marat can you provide the graphics section of your about:support from a browser session that has seen this problem occur?
User Story: (updated)
Flags: needinfo?(mtanalin)
I can reproduce it within 1-2 minutes by close/restore same tab.

I use Mouse Gesture Redox plugin with "down" gesture for closing and "up" for restoring. So it's easy to close and restore.

Open a few tabs and cyclically close/restore the last one with down/up/down/up gesture. Sometimes closing "does not work" and I still see the tab, but it disappears after right click or something.

Mouse Gesture Redox extension:
https://dl.dropboxusercontent.com/u/235592644/files/{FFA36170-80B1-4535-B0E3-A4569E497DD0}.zip

My about:support
https://bugzilla.mozilla.org/show_bug.cgi?id=1065463#c69
(In reply to Jeff Muizelaar [:jrmuizel] from comment #76)
> Unfortunately, this isn't really practical or possible. From a graphics
> point of view there's not really anything special about switching tabs.

Maybe I wasn't clear enough: I suggest to add a temporary _workaround_ (forced repaint on switching tabs) to Firefox code that will make the bug look fixed until Mozilla developers will be able to find and fix the actual reason of the bug. If I can guaranteedly unfreeze my Firefox by doing a certain action, the Firefox itself could automatically imitate this action.

> The best thing for anyone who can reproduce this is to see if they can get a
> regression window using the process described here:
> http://mozilla.github.io/mozregression/

That's in fact inapplicable to this bug. Please see the comment 4.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #77)
> Marat can you provide the graphics section of your about:support from a
> browser session that has seen this problem occur?

I already did this in bug 1123081 comment 5 (just with OMTC disabled), but here it is again (now with OMTC enabled as I currently use Firefox this way due to crashes introduced in Firefox 36 with OMTC disabled) (data obtained with Firefox 36 stable released on 2015-02-24):

Adapter Description: NVIDIA GeForce GTX 650 Ti BOOST
Adapter Drivers: nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Adapter RAM: 2048
Device ID: 0x11c2
Direct2D Enabled: true
DirectWrite Enabled: true (6.2.9200.16492)
Driver Date: 2-5-2015
Driver Version: 9.18.13.4752
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Subsys ID: 356d1458
Vendor ID: 0x10de
WebGL Renderer: Google Inc. -- ANGLE (NVIDIA GeForce GTX 650 Ti BOOST Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d
AzureContentBackend: direct2d
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0
Flags: needinfo?(mtanalin)
FWIW, I've just recorded a video (715 KB) demonstrating the bug:

http://tanalin.com/_experimentz/bugs/fx/2014/repaint/video/

On video, you can see that Firefox window is repainted once title tooltip of a link in the invisible (but actually active) tab is shown.
> I can reproduce it within 1-2 minutes by close/restore same tab.

I recorded a video:
https://dl.dropboxusercontent.com/u/235592644/files/firefox_bugzilla_1067470.wmv.zip (643kb)

Firefox "freezes" at 0:15 and unfreezes after more than a minute! (and tab finally closes)

Unfortunately I was not able to reproduce it with FireGestures extension (which is on AMO) within 5 minutes. That's because I put the link to Gesture Redox extension (looks like it does not work with Nightly)
Can anyone reproduce this issue on hardware other than Nvidia?
(In reply to Jeff Muizelaar [:jrmuizel] from comment #82)
> Can anyone reproduce this issue on hardware other than Nvidia?

I filed two of the duplicated bugs, and I'm on Intel HD3000 - Win7. One of the bugs was with HW On and the other one with HW off. But both with OMTC On.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #82)
> Can anyone reproduce this issue on hardware other than Nvidia?

I filed dupe bug #1130437 and I'm also Intel HD3000 Win 7 x64. Note I'm using x64 builds. The bug includes a video showing what happens and as noted was reproducible with HWA on or off. Since I filed that bug it has not happened a single time. I think maybe there is something I was doing that was CPU intensive, or something, that made it easier for the bug to show itself at that time. Also, since filing that bug I've disabled OMTC due to another bug so that may be why I haven't encountered it.

Just now I tried for ten minutes in a clean profile to reproduce and I can't. Sorry but I can't devote the cumulative amount of time that would be required in my case to create a regression window. It would probably be hours.
Tomorrow I'm going to try to put together a debugging build that people can try which should give us some idea of whether the failure is at the driver level or at a higher one.
Running this build from cmd.exe with the -attach-console flag should print something everytime we try to draw something to the screen. I'd be very interested in seeing the results when firefox stops painting. Do we still print anything? Does the output change?

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-38de7daa04da/try-win32/
umm do we attach the flag to the cmd.exe or firefox.exe?
(In reply to kalviskajaks from comment #87)
> umm do we attach the flag to the cmd.exe or firefox.exe?

Firefox.exe
That build had a small bug in it: there should be a new build showing up once this is done:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=8e9c6d603d21

But results from the first build will still contain some useful information.
> should print something everytime we try to draw something to the screen
It prints only few lines at startup:
d:\!temp\firefox>firefox -attach-console -p
d:\!temp\firefox>221051652 EndFrame: Present
221051284 EndFrame: Present
221051456 EndFrame: Present
221051652 EndFrame: Present
221051652 EndFrame: Present
221051652 EndFrame: Present
221051652 EndFrame: Present

> there should be a new build
no link there
correct link:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-8e9c6d603d21/try-win32/

> It prints only few lines at startup
Ok, it does work without -p
Can you please add a counter or/and timestamp to the output? It's hard to answer your question if you have full window with same line "0 EndFrame: Present"
(In reply to 65feb6b8c9726133b18ac2f2ac26e8bc from comment #92)
> Can you please add a counter or/and timestamp to the output? It's hard to
> answer your question if you have full window with same line "0 EndFrame:
> Present"

Gah, sorry, that was my original intent. A build that properly increments will show up here:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a547c98975d2
(In reply to Jeff Muizelaar [:jrmuizel] from comment #94)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #93)
> > Gah, sorry, that was my original intent. A build that properly increments
> > will show up here:
> > https://treeherder.mozilla.org/#/jobs?repo=try&revision=a547c98975d2
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.
> com-8e9c6d603d21/try-win32/
Wrong link...
(In reply to Jeff Muizelaar [:jrmuizel] from comment #95)
> Wrong link...
I assume you meant
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-a547c98975d2/try-win32/
(In reply to anonbugreport from comment #96)
> I assume you meant
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.
> com-a547c98975d2/try-win32/
Yep.
A key piece of information I'd like to know is if it's possible to get Firefox to print these messages while it has stopped painting, or if they stop and don't start until Firefox starts painting again.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #98)
> A key piece of information I'd like to know is if it's possible to get
> Firefox to print these messages while it has stopped painting, or if they
> stop and don't start until Firefox starts painting again.

I finally managed to get Firefox to freeze while switching tabs with your build.
All I get was "EndFrame: Present".
The console continues printing that while I hover the cursor over the unpainted links, just like it would if the tab did not freeze.
The freeze did not stop Firefox from printing the "EndFrame: Present" messages.
I want to confirm what Marat Tanalin posted above - as of Firefox 36 stable, DISABLING OMTC causes random crashes in Firefox. I'm a user who has had ZERO crashes in Desktop Firefox in the last 2 years. I did notice the issue caused by OMTC a few versions ago, but tried to ignore it. Today morning I decided I had enough and discovered the about:config switch which may alleviate the issue - but since my Firefox had already been upgraded to v36, it looks like I am suffering from the issue Marat pointed out.

This is very concerning, as MANY of those on the Firefox Support website are RECOMMENDING that OMTC be disabled if users are experiencing "freezing" in Firefox - but disabling OMTC in Firefox 36 is now causing CRASHES which is much more severe than a mere "freezing" of the UI! Essentially, your support structure is now worsening the issue...
Flags: needinfo?(bgirard)
(In reply to anonbugreport from comment #99)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #98)
> > A key piece of information I'd like to know is if it's possible to get
> > Firefox to print these messages while it has stopped painting, or if they
> > stop and don't start until Firefox starts painting again.
> 
> I finally managed to get Firefox to freeze while switching tabs with your
> build.
> All I get was "EndFrame: Present".
> The console continues printing that while I hover the cursor over the
> unpainted links, just like it would if the tab did not freeze.
> The freeze did not stop Firefox from printing the "EndFrame: Present"
> messages.

Ok, this suggests that we are asking the driver to present our new frame. So either the driver is not actually presenting the new frame or we're not giving the driver any new data.

If you enable the layers.acceleration.draw-fps preference does the frames per second counter change while Firefox is frozen, but the messages are still being printed?
(In reply to Jeff Muizelaar [:jrmuizel] from comment #101)
> Ok, this suggests that we are asking the driver to present our new frame. So
> either the driver is not actually presenting the new frame or we're not
> giving the driver any new data.

There have been reports of this occurring on Nvidia, AMD, and Intel cards. Could it really be all three vendors have faulty drivers?
My GPU information for reference: http://pastebin.com/x1MQg9nm

> If you enable the layers.acceleration.draw-fps preference does the frames
> per second counter change while Firefox is frozen, but the messages are
> still being printed?

The fps counter froze at "010 010 100" while the messages continue printing.
I've started a new build here:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=7abc29022042

It contains a little bit more logging and a square in the top left that will change color every time we try to Present. The square painting is at a very low level so if we have any ability to draw to the screen it should end up there. I'd be very interested to hear if anyone sees "EndFrame: Present" messages happening without the colored square changing.
Summary: Firefox window is not repainted sometimes after switching tab seems to be caused by OMTC → Firefox window is not repainted sometimes after switching tab seems to be caused by OMTC (fps counter doesn't update)
This looks wrong:

>    if (color == 0xff0000ff)
>          color = 0xffff00ff;
>    else
>          color = 0xff00ffff;

Won't this always end up with the else branch? -> Color not actually changing?
Also dstBox vs srcBox naming and UpdateSubresource afaik takes 5 input parameters (bitmap missing?)
/s/5/6
(In reply to Johannes Pfrang [:johnp] from comment #106)
> /s/5/6

Yeah, this was the wrong version of the patch. The machine with the correct version isn't readily available to me, but I hope to have a new build started soon.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #108)
> This should work better:
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=b14141aa78f7
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/
> jmuizelaar@mozilla.com-b14141aa78f7

Messages continue printing as usual but the square froze.
(In reply to anonbugreport from comment #109)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #108)
> > This should work better:
> > https://treeherder.mozilla.org/#/jobs?repo=try&revision=b14141aa78f7
> > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/
> > jmuizelaar@mozilla.com-b14141aa78f7
> 
> Messages continue printing as usual but the square froze.

Can others who see this bug confirm the same symptoms?
Symptoms about the original issue? Or about your try builds?

About the main issue, I got some random freezes of the UI (almost impossible to reproduce) when switching to a tab, I have to right click to make the context menu appear or switch to another application window to have the hand again (left click) on the Firefox UI.

If I do nothing, it seems to disappear automatically after a few seconds (maybe 5 or 6).
(In reply to Loic from comment #117)
> Symptoms about the original issue? Or about your try builds?
> 
> About the main issue, I got some random freezes of the UI (almost impossible
> to reproduce) when switching to a tab, I have to right click to make the
> context menu appear or switch to another application window to have the hand
> again (left click) on the Firefox UI.
> 
> If I do nothing, it seems to disappear automatically after a few seconds
> (maybe 5 or 6).

Same symptoms with the try builds. i.e. messages are printed in the console but the square in the top does not change color.
gfx.direct2d.disabled = true
layers.offmainthreadcomposition.enabled = false
layers.acceleration.disabled = true

Using those settings in about:config should fix the problem. Can anybody else confirm this?
(In reply to Pikamander2 from comment #119)
Looks like you're effectively just disabling hardware acceleration which is a known workaround for the issue.
FWIW, starting from Firefox 37 beta, I now encounter not just freezes, but also displaying mixed contents of different tabs, which I did never see in Firefox 36 beta.

Moreover, mixed content is then repainted partially (e.g. when I'm hovering different tiles on the new-tab page, the window is repainted in areas of specific tiles I've hovered), not entire window at once.

So mixing content of different tabs is probably a separate bug different from what the current bug is about.
No, it's not the other bug, it's a known that the frozen tab content (e.g. like links) will be shown when you move your mouse cursor on it.
(In reply to Virtual_ManPL [:Virtual] from comment #122)
But this wasn't the case for me until updating from v36 to v37. For example, see the video at the bug URL: once the link is showing title tooltip, the window is repainted entirely at once.
No idea if it's a different bug or not, but I can confirm what Marat Tanalin said is exactly what I encountered and it only happens from beta v37.
Attachment #8572540 - Attachment description: Rendering but on tabs change → Rendering bug on tabs change
I still haven't seen any confirmation of the symptoms experiences by anonbugreport@mailinator.com in comment 109. Does anyone else see the same thing. I'm not that interested in FF37 results because 37 has partial present which will complicate the reporting further.
I have tried using your try build based on FF36 but it crashed continuosly, and I couldn't reach to see the bug. I tried creating lots of tabs, but it wasn't useful...
(In reply to marco_pal from comment #127)
> I have tried using your try build based on FF36 but it crashed continuosly,
> and I couldn't reach to see the bug. I tried creating lots of tabs, but it
> wasn't useful...

The crashes might be pointing at a problem. Can you try the build that shows up here?
https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-0fd3e9ab7052

It will hopefully not have the same crashes and give useful information.
Flags: needinfo?(marco_pal)
In the old build firefox crashed on:
-after a few characters typed in the location bar
-when opening the dropdown box dialog for activating/disabling/ask in the plugin page
-i'm not sure but also maybe when unloading flash

The new one doesn't crash anymore but doing the same actions make the interface freeze. Not only the page but also the chrome is freezed. The colored box was freezed as well but in the console was printing continuosly "4422 EndFrame: Present 887a0005", the last number is always the same and before freezing is 0. I was in the addons page, the page somehow worked because using tooltips and mouse cursors I was able to move and change sections. I must mention that while the windows was completely freezed, dialog appeared, like the right click one and the "hamburger" dialog, both in page and in chrome. Even the preference window appeared without a problem. I must mention that while this happened the colored box didn't appear at all in these windows/dialogs while before crashing it appeared everywhere. The last thing I noted is that after freezing only the repainting in the freezed gui are reported but everything else (other dialogs) aren't printing messages as before. If I minimize the windows it becomes completely white.
I can freeze the gui on demand in this build so if you want other info I'm here ;-)
Flags: needinfo?(marco_pal)
A correction: in the new build the location bar dosn't seem to crash anymore, but in the addon page it crash also if I right click somewhere and not only in ask/deny menu of each plugin.
I made a recording, in a few hours should be online and I try to post it here.
(In reply to marco_pal from comment #129)
> In the old build firefox crashed on:
> -after a few characters typed in the location bar
> -when opening the dropdown box dialog for activating/disabling/ask in the
> plugin page
> -i'm not sure but also maybe when unloading flash
> 
> The new one doesn't crash anymore but doing the same actions make the
> interface freeze. Not only the page but also the chrome is freezed. The
> colored box was freezed as well but in the console was printing continuosly
> "4422 EndFrame: Present 887a0005", the last number is always the same and
> before freezing is 0.

887a0005 is DXGI_ERROR_DEVICE_REMOVED. I've started a new build that will show up here that may give more information on what is happening. 

https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-57ece2616b0d

Do you have any guesses as to what might be causing this error?
This builds doens't add anything new because it prints "73 EndFrame: Present 887a0005 reason 887a0005" ...
I had problems uploading the video, now I'm trying with a different file hosting. I don't know what could be the culprit...
However is there something different between this and the standard release builds? Because I don't have these problems in release. These bug was extremely rare to happen and it recovered after a few seconds, instead here crash a lot...
I realized I left another MOZ_CRASH in the build. Try the build that shows up here should crash less and give more information about the d3d11 device that we're using:

https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-3f977c607fc1
Flags: needinfo?(marco_pal)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #133)
> I realized I left another MOZ_CRASH in the build. Try the build that shows
> up here should crash less and give more information about the d3d11 device
> that we're using:
> 
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/
> jmuizelaar@mozilla.com-3f977c607fc1

Your latest build produces similar results as before except that it prints "EndFrame: Present(1b6b3c, 12320d88) 0".
I experienced no crash or any DXGI_ERROR_DEVICE_REMOVED errors. Though I managed to trigger the bug rather early at around the 3600th EndFrame.

(In reply to marco_pal from comment #129)
> I can freeze the gui on demand in this build so if you want other info I'm
> here ;-)

How exactly do you get the freeze to happen on demand? If it is 100% reproducible, I could see about getting that regression window.
(In reply to anonbugreport from comment #134)
> Your latest build produces similar results as before except that it prints
> "EndFrame: Present(1b6b3c, 12320d88) 0".

Do the numbers inside Present change when the rendering stops/starts again?
Flags: needinfo?(anonbugreport)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #135)
> (In reply to anonbugreport from comment #134)
> > Your latest build produces similar results as before except that it prints
> > "EndFrame: Present(1b6b3c, 12320d88) 0".
> 
> Do the numbers inside Present change when the rendering stops/starts again?

Nope. It stays the same. Only the counter at the start changes.
Flags: needinfo?(anonbugreport)
https://mega.co.nz/#!nQBBBThY!DjIHY7NnXBAn2EKcpgoh7yNRaOUfeDPbqsNFShVUj8M
https://mega.co.nz/#!CYIlnb6b!7VsC5OxxqtZ5ad31F9HXR-s-LyMoI-dqt5I6jLKvgcw
Here I'm am again, the first video was with the first build and the second with the latest one. The behavior isn't always exactly the same, it changes a little if I make it freeze using the button instead of using the right click, or something else... However I recorded this one because it seems to have more information. As you can see after it freeze the preference window that I open works but doesn't print or show a rectangle so it must render using another path. 
But you can also note two different things: the right click dialog that I use to freeze prints but doesn't appear; and there are also dialogs that show with a freezed rectangle while printing WITHOUT ERRORS. And during all of these the original device stays the same.
At the end I make it crash using right click on the transparent bar but it doesn't always crash like that depending on what I press before.
Flags: needinfo?(marco_pal)
What commands should I be using for mozregression?

I assume since the bug was not present in Firefox 32 I should use the command "mozregression --bits 32 --good-release 32 --bad-release 33".
This results in the following window.
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9305a8ec77fe&tochange=9dc0ffca10f4

The tests was performed by holding down Ctrl+Tab to cycle through the tabs rapidly while occasionally right clicking a tab. The right clicking seems to help trigger the bug (It might just be placebo). Since I could not reproduce it consistently, I just went for brute force.

Also while the bug is present in a clean profile, installing the addon Stylish seems to trigger it much more frequently.
@anonbugreport
If you make the same actions as I do in the video, does it behave like mine? I mean freeze in the addon tab.
(In reply to marco_pal from comment #139)
> @anonbugreport
> If you make the same actions as I do in the video, does it behave like mine?
> I mean freeze in the addon tab.

I tried, but experienced no crash or blank context menu.
marco_pal I've split your issue out into a separate bug because it's more reproducible and has some different symptoms. The new bug is bug 1141073
anonbugreport can you try to figure out as much information about what causes the browser to start painting again after it stops?
Flags: needinfo?(anonbugreport)
clicking on other tabs/ minimizing maximizing = browser repaints

moving mouse/waiting = never repaints ?
(In reply to kalviskajaks from comment #144)
> clicking on other tabs/ minimizing maximizing = browser repaints
> 
> moving mouse/waiting = never repaints ?

How about switching the focus to another program and back to Firefox?
(In reply to Jeff Muizelaar [:jrmuizel] from comment #145)
> (In reply to kalviskajaks from comment #144)
> > clicking on other tabs/ minimizing maximizing = browser repaints
> > 
> > moving mouse/waiting = never repaints ?
> 
> How about switching the focus to another program and back to Firefox?

And how about switching to a tab that has the same title. Does that fix it?
How about resizing the window. Does that fix it?
(In reply to Jeff Muizelaar [:jrmuizel] from comment #147)
> How about resizing the window. Does that fix it?

Yes, for me double clicking the window to make it full screen *does* fix the issue 100% of the time. I haven't tried manually dragging the window to a larger size though. The next time the issue occurs I can try this or switching to another program and back.

(I'm the one who filed the duped bug 1140968 FWIW)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #143)
> anonbugreport can you try to figure out as much information about what
> causes the browser to start painting again after it stops?

Right clicking (open context menu)
Opening the options menu
Switching window focus
Minimizing
Resizing
Waiting (sometimes? not sure)

Probably anything except interacting with the page normally. Scrolling, switching tabs, closing tabs, does not cause a repaint.
Flags: needinfo?(anonbugreport)
Not sure if it's still needed, I made a crash when not painting corrcectly:

https://crash-stats.mozilla.com/report/index/6a52f94b-9030-4320-a5db-2fce52150311
anonbugreport, does the content of the tabs matter? Can you reproduce the bug using tabs that just contain about:blank?
Flags: needinfo?(anonbugreport)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #151)
> anonbugreport, does the content of the tabs matter? Can you reproduce the
> bug using tabs that just contain about:blank?

We probably won't know if the bug occurred because we can't compare page content in about:blank as it doesn't have one.
(In reply to Virtual_ManPL [:Virtual] from comment #152)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #151)
> > anonbugreport, does the content of the tabs matter? Can you reproduce the
> > bug using tabs that just contain about:blank?
> 
> We probably won't know if the bug occurred because we can't compare page
> content in about:blank as it doesn't have one.

The selected tab should show the tab not changing though.
This could just be a random coincidence, but I was regularly able to reproduce this bug for the last month, but for the last two days haven't gotten a single occurrence. The only thing I changed two days ago is removing a pinned tab with the following content: http://techblog.netflix.com/search/label/JavaScript (I never really looked at this tab, it was just a way of keeping a "todo" for something I wanted to read)
I just added the pinned tab back and the bug reproduced! So maybe something to try.
Also, anonbugreport, is it possible for you to make a screencapture of you reproducing the problem?
(In reply to bugzilla_mozilla from comment #154)
> This could just be a random coincidence, but I was regularly able to
> reproduce this bug for the last month, but for the last two days haven't
> gotten a single occurrence. The only thing I changed two days ago is
> removing a pinned tab with the following content:
> http://techblog.netflix.com/search/label/JavaScript (I never really looked
> at this tab, it was just a way of keeping a "todo" for something I wanted to
> read)
> I just added the pinned tab back and the bug reproduced! So maybe something
> to try.

If you disable flash are you able to still able to reproduce the problem?
Flags: needinfo?(bugzilla_mozilla)
I'll try disabling flash after I've reproduced it a few more times so I can have a bit more confidence that the change is related.

But I do have an answer to a prior question. I just reproduced the issue again and can confirm that putting focus on a different application and then returning focus to firefox *does* resolve the issue. The firefox window was not resized at all and the only click was on the upper part to refocus the window.
Flags: needinfo?(bugzilla_mozilla)
I have a new build coming up here that does a readback of the destination in an attempt to see if it's our writing to swap chain that's broken or the DWM's presentation of the frames.

I'd also be interested to know if anyone can reproduce the problem with the DWM turned off.
(In reply to bugzilla_mozilla from comment #157)
> I'll try disabling flash after I've reproduced it a few more times so I can
> have a bit more confidence that the change is related.
> 
> But I do have an answer to a prior question. I just reproduced the issue
> again and can confirm that putting focus on a different application and then
> returning focus to firefox *does* resolve the issue. The firefox window was
> not resized at all and the only click was on the upper part to refocus the
> window.

Does it only happen with http://techblog.netflix.com/search/label/JavaScript pinned? or can you pin other tabs and reproduce the problem? Does http://techblog.netflix.com/search/label/JavaScript need to be pinned or can it just be open? What about using a single post from the blog like http://techblog.netflix.com/2015/01/netflix-likes-react.html? Does that help reproduce the problem?
Flags: needinfo?(bugzilla_mozilla)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #159)
> (In reply to bugzilla_mozilla from comment #157)
> > I'll try disabling flash after I've reproduced it a few more times so I can
> > have a bit more confidence that the change is related.
> > 
> > But I do have an answer to a prior question. I just reproduced the issue
> > again and can confirm that putting focus on a different application and then
> > returning focus to firefox *does* resolve the issue. The firefox window was
> > not resized at all and the only click was on the upper part to refocus the
> > window.
> 
> Does it only happen with http://techblog.netflix.com/search/label/JavaScript
> pinned? or can you pin other tabs and reproduce the problem? Does
> http://techblog.netflix.com/search/label/JavaScript need to be pinned or can
> it just be open? What about using a single post from the blog like
> http://techblog.netflix.com/2015/01/netflix-likes-react.html? Does that help
> reproduce the problem?

All great questions! I'll try to get answers but it may take awhile due to the infrequency at which I can reproduce. I'm going to try to be methodical about it and record occurrences under different circumstances. Ideally I'd like to have a bunch of different occurrences before I move onto the next test, and each occurrence can take multiple hours of heavy usage. So stay tuned...
Flags: needinfo?(bugzilla_mozilla)
The bug is not related to pinning since I almost never pin anything yet experience the bug.

The bug is solely related to tab creating/closing/switching.
(In reply to Marat Tanalin | tanalin.com from comment #161)
> The bug is not related to pinning since I almost never pin anything yet
> experience the bug.
> 
> The bug is solely related to tab creating/closing/switching.

It's possible different circumstances could tickle the same underlying issue, so I wouldn't be so quick to dismiss other investigation paths especially given that this bug has been open for 6 months with little progress and no reproducible cases.
Summary: Firefox window is not repainted sometimes after switching tab seems to be caused by OMTC (fps counter doesn't update) → Firefox window is not repainted sometimes after switching tab seems to be caused by OMTC (fps counter doesn't update/Present stops working)
I'm also experiencing this issue, and was going to create a new ticket but I found this one already. It's difficult to reproduce as has been said, as it only happens occasionally. Sometimes if I'm switching from a text page to a you tube video, the box for the video will overlay the previous tab partially, as if the new tab is halfway loaded. When it does freeze, I simply minimize Firefox, and when I maximize again, the tab has switched. It seems like this has been talked about for a long time, so I'm probably no help here, but if I can help by giving more information, let me know.
Same here.
Almost random and annoying issue.
Summary: Firefox window is not repainted sometimes after switching tab seems to be caused by OMTC (fps counter doesn't update/Present stops working) → Firefox window is not repainted sometimes after switching tab (seems to be caused by OMTC; fps counter doesn't update / Present stops working)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #156)
> If you disable flash are you able to still able to reproduce the problem?

FWIW, the bug appears regardless of whether Flash is enabled or disabled. Tested on Firefox 38.0a2 (20150313004057, x64) with Flash disabled.
Whiteboard: [if you can reproduce it often - see comment 23] → [if you can reproduce it often - see comment 23][gfx-noted]
Has anyone had a chance to test this build: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-0270fbc337a9

with -attach-console ?
(In reply to Jeff Muizelaar [:jrmuizel] from comment #167)
> Has anyone had a chance to test this build:
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/
> jmuizelaar@mozilla.com-0270fbc337a9
> 
> with -attach-console ?

I can't get that build to freeze for some reason.
Flags: needinfo?(anonbugreport)
I haven't seen this bug in the last few Nightlies (maybe the whole last week). If others confirm this, maybe it got fixed.
I think i have, but it goes away after a moment. It used to stay bugged if i didn't do anything, but now it just bugs out for like a halfsecond or less and goes back to normal. Either that or i have been just lucky and haven't triggered the bug so hard anymore. I use nightly. Haven't tried the build Jeff is offering.
Just made another crash for that.

At least on beta, this bug is very frequent and painful as hell especially when you're browsing image intensive websites. 

https://crash-stats.mozilla.com/report/index/bp-38198586-947a-4011-ae60-5b9b52150317
(In reply to Guilherme Lima from comment #170)
> I haven't seen this bug in the last few Nightlies (maybe the whole last
> week). If others confirm this, maybe it got fixed.

Just happened again on the lastest Nightly, so it was a false alarm.
(In reply to Benjamin Peng from comment #172)
> https://crash-stats.mozilla.com/report/index/bp-38198586-947a-4011-ae60-
> 5b9b52150317

Unfortunately it's misleading tail.
I had the same crash signature when I force crash Nightly when we had bug #1064864 (some more info in dupe bug #1060726)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #175)
> Please try reproducing with this build:
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/
> jmuizelaar@mozilla.com-0270fbc337a9

Used it a bit. Didnt encounter the bug yet. I do crash every time i try to use reddit search box though, which doesnt happen with newest nightly.  https://crash-stats.mozilla.com/report/index/a6ecb114-51d8-470e-a0f8-257012150318
More crashing when interacting with the allow plugin box. https://crash-stats.mozilla.com/report/index/1dc19ad7-c0ac-4c6d-9806-3c09c2150318 And the flashing rectangle is right in the way in all menus while trying to use the browser. Would it be possible to place it at bottom right corner where there is usually blank space in all windows, if that isnt too hard?
Seems, like the crashes that I had a few comments ago. By the way, they happens in same way also in the latest build and with the same signature as you. However I'm not sure it's the same bug, as the crashes happens to me only in this trybuilds, on the release build the bug happens rarely and never crashes. It was splitted in another bug by Jeff, if you see the previous comments.
I don't know if you're able to know something by the address in the crash report which are the same
Yes i see https://bugzilla.mozilla.org/show_bug.cgi?id=1141073 no progress there though.
I think this build might fix the crash:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-84df7b5a88d6/try-win32/

Can you see if you can reproduce with it?
There will be a new build here:
https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-822f176d0766

That should either not crash or print a message before it does crash.
Whiteboard: [if you can reproduce it often - see comment 23][gfx-noted] → [gfx-noted]
The last build I think didn't worked. I also written a recap in the other bug.
Yes the directory is empty, unless its meant to take several days to compile or smth.
Yeah, that one had a build problem. I have a new one started that should show up here:

https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-fb557a9f924c/
(In reply to Jeff Muizelaar [:jrmuizel] from comment #186)
> Yeah, that one had a build problem. I have a new one started that should
> show up here:
> 
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/
> jmuizelaar@mozilla.com-fb557a9f924c/

https://crash-stats.mozilla.com/report/index/199d91f2-daee-4d89-bf72-bafc12150323

crash on using reddit search, log ended with 

°598 EndFrame: Present(a8f76c, 11fee6b0) 0
value: ffff58ff
599 EndFrame: Present(a8f76c, 23b39248) 0
value: ff0059ff
600 EndFrame: Present(a8f76c, 11fee6b0) 0
value: ffff5aff
601 EndFrame: Present(a8f76c, 11fee6b0) 0
value: ff005bff
602 EndFrame: Present(a8f76c, 11fee6b0) 0
Texture creation failed with 887a0005

and https://crash-stats.mozilla.com/report/index/3819e65e-50e6-4a17-b08b-c81272150323

crash on interacting with allow plugins box, log ended with

752 EndFrame: Present(6cacfc, 11ba7d90) 0
value: fffff2ff
753 EndFrame: Present(6cacfc, 11ba7d90) 0
value: ff00f3ff
754 EndFrame: Present(6cacfc, 11ba7d90) 0
Texture creation failed with 887a0005
Some random thoughts: 

This bug is more often when viewing image-heavy tabs. It almost guaranteed to happen when I switch between two tabs with large resolution images (4000x5000+). 

It's much easier to happen when I use Firefox for a while, instead of just opened it. So memory usage could be quite relevant to Firefox's rendering efficiency/performance.

And it rarely happens when I'm testing in safe mode (still happens, but way less frequent) so it means (a lot of) addons would aggravate the issue.
(In reply to kalviskajaks from comment #189)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #186)
> > Yeah, that one had a build problem. I have a new one started that should
> > show up here:
> > 
> > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/
> > jmuizelaar@mozilla.com-fb557a9f924c/
> 
> https://crash-stats.mozilla.com/report/index/199d91f2-daee-4d89-bf72-
> bafc12150323
> 
> crash on using reddit search, log ended with 
> 
> °598 EndFrame: Present(a8f76c, 11fee6b0) 0
> value: ffff58ff
> 599 EndFrame: Present(a8f76c, 23b39248) 0
> value: ff0059ff
> 600 EndFrame: Present(a8f76c, 11fee6b0) 0
> value: ffff5aff
> 601 EndFrame: Present(a8f76c, 11fee6b0) 0
> value: ff005bff
> 602 EndFrame: Present(a8f76c, 11fee6b0) 0
> Texture creation failed with 887a0005
> 
> and
> https://crash-stats.mozilla.com/report/index/3819e65e-50e6-4a17-b08b-
> c81272150323
> 
> crash on interacting with allow plugins box, log ended with
> 
> 752 EndFrame: Present(6cacfc, 11ba7d90) 0
> value: fffff2ff
> 753 EndFrame: Present(6cacfc, 11ba7d90) 0
> value: ff00f3ff
> 754 EndFrame: Present(6cacfc, 11ba7d90) 0
> Texture creation failed with 887a0005

Same for me, same crashes also https://crash-stats.mozilla.com/report/index/e795cd8d-c1fa-4f07-af16-92c3e2150320
We're now at the end of the 37 cycle. As we have shipped 3 releases with this bug already, I'm not going to block on this issue for 37. Please keep pushing for 38 as we absolutely do want to fix this as soon as we can identify the source of the problem.
status-firefox37: affected → wontfix
(In reply to Jeff Muizelaar [:jrmuizel] from comment #186)
> Yeah, that one had a build problem. I have a new one started that should
> show up here:
> 
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/
> jmuizelaar@mozilla.com-fb557a9f924c/

How are we supposed to use this? Can it be the zip build?

I ran "firefox -attach-console -p -no-remote" and nothing is printed on cmd.exe, is that it?
(In reply to Rodze from comment #194)
> How are we supposed to use this? Can it be the zip build?
> 
> I ran "firefox -attach-console -p -no-remote" and nothing is printed on
> cmd.exe, is that it?

The zip build works. It just doesn't work with "-p".
I found a way to replicate the freeze at least on my machine, the key beeing windows tooltips:
1. Open several Firefox tabs.
2. Move the mouse at the tab header of an inactive tab and at the very moment the tooltip appears, click the mouse to switch to that tab. You not always get the timing right, as you have to be very quick.

In short: If tooltip is displayed at the same moment while the tab is getting activated, the tab freezes.
(In reply to Miks from comment #196)
> I found a way to replicate the freeze at least on my machine, the key beeing
> windows tooltips:
> 1. Open several Firefox tabs.
> 2. Move the mouse at the tab header of an inactive tab and at the very
> moment the tooltip appears, click the mouse to switch to that tab. You not
> always get the timing right, as you have to be very quick.
> 
> In short: If tooltip is displayed at the same moment while the tab is
> getting activated, the tab freezes.

WOW. Ingenious finding.. I can reproduce it.
I should mention it's not always "reproducible". You need to use Firefox for a while (better in a heavy profile) until it became kinda "lagging"; and then this trick would produce the rendering bug every time you click at the exact momennt he said.
(In reply to Benjamin Peng from comment #197)
> (In reply to Miks from comment #196)
> > I found a way to replicate the freeze at least on my machine, the key beeing
> > windows tooltips:
> > 1. Open several Firefox tabs.
> > 2. Move the mouse at the tab header of an inactive tab and at the very
> > moment the tooltip appears, click the mouse to switch to that tab. You not
> > always get the timing right, as you have to be very quick.
> > 
> > In short: If tooltip is displayed at the same moment while the tab is
> > getting activated, the tab freezes.
> 
> WOW. Ingenious finding.. I can reproduce it.

At the moment I am evaluating the possible fix of this edit:
browser.chrome.toolbar_tips = false
(In reply to Miks from comment #199)
> (In reply to Benjamin Peng from comment #197)
> > (In reply to Miks from comment #196)
> > > I found a way to replicate the freeze at least on my machine, the key beeing
> > > windows tooltips:
> > > 1. Open several Firefox tabs.
> > > 2. Move the mouse at the tab header of an inactive tab and at the very
> > > moment the tooltip appears, click the mouse to switch to that tab. You not
> > > always get the timing right, as you have to be very quick.
> > > 
> > > In short: If tooltip is displayed at the same moment while the tab is
> > > getting activated, the tab freezes.
> > 
> > WOW. Ingenious finding.. I can reproduce it.
> 
> At the moment I am evaluating the possible fix of this edit:
> browser.chrome.toolbar_tips = false

I can still reproduce the problem with comment #196 in Firefox 37b7, even if I made the browser.chrome.toolbar_tips = false.
(In reply to Miks from comment #196)
> I found a way to replicate the freeze at least on my machine, the key beeing
> windows tooltips:
> 1. Open several Firefox tabs.
> 2. Move the mouse at the tab header of an inactive tab and at the very
> moment the tooltip appears, click the mouse to switch to that tab. You not
> always get the timing right, as you have to be very quick.
> 
> In short: If tooltip is displayed at the same moment while the tab is
> getting activated, the tab freezes.

Nice work. I was also able to reproduce this bug quite easily with this method. It took maybe 10 or 15 tab switches for me.
If you guys can reproduce it really well, maybe we can finally get some answers. Does disabling desktop composition help? Disabling addons? Safe mode?
anonbugreport, can you reproduce the issue using the tooltip method?
Flags: needinfo?(anonbugreport)
On my system I had no issues with this (Win7 SP1 x64 + GTX770) until I upgraded to Fx36. Reverting to Fx35 and prior have no issues on this system. If I disable OMTC on Fx36, no issue.

I first noticed it with the DownThemAll add-on, which temporary shows a notification bar on the bottom of the browser when you use dTA-OneClick, telling you how many items are queued. If you navigate to a new page when this bar is active, the notification bar and the entire browser page flashes black for almost a second. 

I can also reproduce it on the image gallery half-way down in this Ars article. Every couple times pressing the arrow or thumbnails to show the next image (scrolling animation), the entire gallery frame will flash black. http://arstechnica.com/gaming/2015/03/battlefield-hardline-single-player-impressions-forget-about-procedure/

I'm also starting to see the issue with parts of pages temporarily flashing black when I switch tabs.

While it all sounds similar, are elements temporarily flashing black with OMTC the same issue as this bug? Or is this actually an unrelated OMTC regression in Fx36?
(In reply to Jeff Muizelaar [:jrmuizel] from comment #203)
> anonbugreport, can you reproduce the issue using the tooltip method?

I can't. However I can't qualify for the requirement of being "very quick". A frame accurate action is beyond me.
Another alternative to freezing Firefox is to try opening multiple images from the wikimedia page on Google Art Project and switching between them.
Its not 100% reproducible for me but it occurs multiple times in a minute.
https://commons.wikimedia.org/wiki/Category:Gigapixel_images_from_the_Google_Art_Project
Flags: needinfo?(anonbugreport)
To clarify.
I could not reproduce the issue using the tooltip method in 36.0.4.
I could reproduce the issue in a couple of minutes using the gigapixel images in 36.0.4.
I could reproduce the issue with a clean profile though less frequently in 36.0.4.

I could not reproduce the issue in the current try-build (fb557a9f924c) using any method or profile.
There are a couple of freezes but they rarely last more than half a second and require no intervention to unfreeze.

Is it be too late to apply the fix from fb557a9f924c to 37?
fb557a9f924c is very crash happy though.
(In reply to anonbugreport from comment #206)
> To clarify.
> I could not reproduce the issue using the tooltip method in 36.0.4.
> I could reproduce the issue in a couple of minutes using the gigapixel
> images in 36.0.4.
> I could reproduce the issue with a clean profile though less frequently in
> 36.0.4.
> 
> I could not reproduce the issue in the current try-build (fb557a9f924c)
> using any method or profile.
> There are a couple of freezes but they rarely last more than half a second
> and require no intervention to unfreeze.
> 
> Is it be too late to apply the fix from fb557a9f924c to 37?

Which images are you using? Most of those gigapixel images are too big to load in Firefox.
Flags: needinfo?(anonbugreport)
I've started a new build that adds some logging around the showing of tooltips. I'd be interested in getting a log from anyone who can reproduce it via tooltips using the build that shows up here https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-7ff9b169a0df
(In reply to Jeff Muizelaar [:jrmuizel] from comment #208)
> (In reply to anonbugreport from comment #206)
> > To clarify.
> > I could not reproduce the issue using the tooltip method in 36.0.4.
> > I could reproduce the issue in a couple of minutes using the gigapixel
> > images in 36.0.4.
> > I could reproduce the issue with a clean profile though less frequently in
> > 36.0.4.
> > 
> > I could not reproduce the issue in the current try-build (fb557a9f924c)
> > using any method or profile.
> > There are a couple of freezes but they rarely last more than half a second
> > and require no intervention to unfreeze.
> > 
> > Is it be too late to apply the fix from fb557a9f924c to 37?
> 
> Which images are you using? Most of those gigapixel images are too big to
> load in Firefox.

It doesn't need to be that large, normally opening several tabs with resolution of 5000x5000+ images would cause noticeable lagging in UI operation (switching tabs, etc.)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #208)
> Which images are you using? Most of those gigapixel images are too big to
> load in Firefox.

It doesn't need to be displayed. It fails to repaint very frequently if you switch between the images that are loading. However I doubt its related to the images directly as I have gotten the bug just by switching between 2 bugzilla tabs.
Flags: needinfo?(anonbugreport)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #209)
> I've started a new build that adds some logging around the showing of
> tooltips. I'd be interested in getting a log from anyone who can reproduce
> it via tooltips using the build that shows up here
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/
> jmuizelaar@mozilla.com-7ff9b169a0df

I managed to reproduce with your build, but the log is scrolling so fast, that by the point i manage to focus on the command window several hundred lines have passed and the point at which the bug happened has long passed..
Ok i think i got it. I opened less tabs and manged to reproduce without the command window beeing spammed with liones, probably one of the tabs before was repeadiatly refreshing or something. Anyways. Here it is 
SetSize
SetSize
value: ff0009ff
8 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ffff0aff
9 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ff000bff
10 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ffff0cff
11 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff000dff
12 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff0eff
13 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ff000fff
14 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff10ff
SetSize
15 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
SetSize
value: ff0011ff
16 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff12ff
17 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0013ff
18 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff14ff
19 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0015ff
20 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ffff16ff
21 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0017ff
22 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ffff18ff
23 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0019ff
24 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ffff1aff
25 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff001bff
26 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ffff1cff
27 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff001dff
28 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff1eff
29 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff001fff
30 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff20ff
31 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
SetSize
value: ff0021ff
32 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
SetSize
value: ffff22ff
33 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0023ff
34 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
SetSize
value: ffff24ff
35 EndFrame: Present(b3001c, 1200c2c8) 0
Show
Click
SetSize
SetSize
value: ff0025ff
36 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ffff26ff
37 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
>>> installPolicy shouldProcess() ...
SetSize
value: ff0027ff
38 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ffff28ff
39 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0029ff
40 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
SetSize
SetSize
value: ffff2aff
41 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff002bff
42 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff2cff
43 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff002dff
44 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff2eff
45 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff002fff
46 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff30ff
47 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0031ff
48 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff32ff
49 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0033ff
50 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff34ff
51 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0035ff
52 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff36ff
53 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0037ff
54 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff38ff
55 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0039ff
56 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff3aff
57 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff003bff
58 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff3cff
59 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff003dff
60 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff3eff
61 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff003fff
62 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ffff40ff
63 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ff0041ff
64 EndFrame: Present(b3001c, 1200c2c8) 0
ShowTooltip
SetSize
SetSize
Show
value: ffff42ff
65 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0043ff
66 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff44ff
67 EndFrame: Present(b3001c, 1200c2c8) 0
Show
SetSize
SetSize
value: ff0045ff
68 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff46ff
69 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0047ff
70 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
SetSize
value: ffff48ff
71 EndFrame: Present(b3001c, 1200c2c8) 0
Click
SetSize
SetSize
SetSize
value: ff0049ff
72 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
SetSize
value: ffff4aff
73 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ff004bff
74 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ffff4cff
75 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ff004dff
76 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff4eff
77 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ff004fff
78 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
SetSize
value: ffff50ff
79 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0051ff
80 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ffff52ff
81 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ff0053ff
82 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ffff54ff
83 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0055ff
84 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff56ff
85 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0057ff
86 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff58ff
87 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0059ff
88 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ffff5aff
89 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff005bff
90 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff5cff
91 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff005dff
92 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
SetSize
ShowTooltip
value: ffff5eff
93 EndFrame: Present(b3001c, 1200c2c8)SetSize
 0
SetSize
Show
value: ff005fff
94 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ffff60ff
95 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ff0061ff
96 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff62ff
97 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
SetSize
value: ff0063ff
98 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ffff64ff
99 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ff0065ff
100 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff66ff
101 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0067ff
102 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff68ff
103 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
SetSize
value: ff0069ff
104 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ffff6aff
105 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff006bff
106 EndFrame: Present(b3001c, 1200c2c8) 0
Click
SetSize
Show
value: ffff6cff
107 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ff006dff
108 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff6eff
109 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff006fff
110 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff70ff
111 EndFrame: Present(b3001c, 1200c2c8) 0
SetSize
value: ff0071ff
112 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff72ff
113 EndFrame: Present(b3001c, 1200c2c8) 0
value: ff0073ff
114 EndFrame: Present(b3001c, 1200c2c8) 0
value: ffff74ff
115 EndFrame: Present(b3001c, 1200c2c8) 0
Click
value: ff0075ff
116 EndFrame: Present(b3001c, 1200c2c8) 0

the last click and 2 lines after that, printed after the freeze when i clicked on the tab again to make sure im really frozen.
Anyways disabling DESKTOP COMPOSITION did NOT help. And the click who triggered the freeze in the log in my previous post should be the one which comes after 106
There will be a new build with more verbose logging that shows up here:
https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-ef66e791869f

If you could try to reproduce the same thing again with this build that would be helpful.
Flags: needinfo?(kalviskajaks)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #215)
> There will be a new build with more verbose logging that shows up here:

Jeff, it would be nice if you were posting links that are already working instead of links to something that will probably be available in the future. This would prevent people from the need to check whether the link is already live on their own, and therefore more people could participate in testing without wasting time. Thanks.
(In reply to Marat Tanalin | tanalin.com from comment #216)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #215)
> > There will be a new build with more verbose logging that shows up here:
> 
> Jeff, it would be nice if you were posting links that are already working
> instead of links to something that will probably be available in the future.
> This would prevent people from the need to check whether the link is already
> live on their own, and therefore more people could participate in testing
> without wasting time. Thanks.

The build above had a problem. I'll post again when the replacement build that will show up here is done:  https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-854543f58dd8
Tracking this for 39 and 40. Florin, do we have anyone on your team who can reproduce this? It sounds like we have made more headway on this and more testing on Jeff's new build(s) could help.
tracking-firefox39: ? → +
tracking-firefox40: ? → +
Flags: needinfo?(florin.mezei)
Disabling all plugins and addons, even the one dictionary i had, DID NOT help. So its purely firefox fault.

I had trouble getting a useful log with the new build because the method which works the best for me. Opening several of the gigapixel images in https://commons.wikimedia.org/wiki/Category:Gigapixel_images_from_the_Google_Art_Project to load( they actually never finish loading, or show correctly but  that doesnt matter you just have to open them in tabs so firefox tries to load them) floods the console withe hundreds of lines per second all the time making it impossible to get any useful log. I will try to trigger a freeze without loading the images.
i can repro this by opening 5-10 images in new tabs, viewing one and closing them one by one. image heavy pages cause it to happen more often too. as a temp work around i turned off HWA which seems to fix it.
Ok i got it

ShowTooltip
SetSize 0BB71C00, 9 22
SetSize 0E910000, 316 173
Show 0BB71C00 2 1
value: ff004dff
2892 EndFrame: Present(23fefcc, 11f27920) 0
Click 0E910000
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
Show 0BB71C00 2 0
value: ffff4eff
2893 EndFrame: Present(23fefcc, 11f27920) 0
value: ff004fff
2894 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff50ff
2895 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0051ff
2896 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff52ff
2897 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0053ff
2898 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff54ff
2899 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0055ff
2900 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff56ff
2901 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0057ff
2902 EndFrame: Present(23fefcc, 11f27920) 0
Click 0E910000
value: ffff58ff
2903 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0059ff
2904 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff5aff
2905 EndFrame: Present(23fefcc, 11f27920) 0
value: ff005bff
2906 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff5cff
2907 EndFrame: Present(23fefcc, 11f27920) 0
value: ff005dff
2908 EndFrame: Present(23fefcc, 11f27920) 0
Click 0E910000
value: ffff5eff
2909 EndFrame: Present(23fefcc, 11f27920) 0
value: ff005fff
2910 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff60ff
2911 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0061ff
2912 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff62ff
2913 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0063ff
2914 EndFrame: Present(23fefcc, 11f27920) 0
Click 0E910000
value: ffff64ff
2915 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0065ff
2916 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff66ff
2917 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0067ff
2918 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff68ff
2919 EndFrame: Present(23fefcc, 11f27920) 0
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
value: ff0069ff
2920 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff6aff
2921 EndFrame: Present(23fefcc, 11f27920) 0
value: ff006bff
2922 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff6cff
2923 EndFrame: Present(23fefcc, 11f27920) 0
value: ff006dff
2924 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff6eff
2925 EndFrame: Present(23fefcc, 11f27920) 0
value: ff006fff
2926 EndFrame: Present(23fefcc, 11f27920) 0
ShowTooltip
SetSize 0BB71C00, 9 22
SetSize 0E910000, 316 173
Show 0BB71C00 2 1
value: ffff70ff
2927 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0071ff
2928 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff72ff
2929 EndFrame: Present(23fefcc, 11f27920) 0
Click 0E910000
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
Show 0BB71C00 2 0
value: ff0073ff
2930 EndFrame: Present(23fefcc, 11f27920) 0
SetSize 0E910000, 316 173
value: ffff74ff
2931 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0075ff
2932 EndFrame: Present(23fefcc, 11f27920) 0
SetSize 0E910000, 316 173
value: ffff76ff
2933 EndFrame: Present(23fefcc, 11f27920) 0
SetSize 0E910000, 316 173
value: ff0077ff
2934 EndFrame: Present(23fefcc, 11f27920) 0
ShowTooltip
SetSize 0BB71C00, 9 22
SetSize 0E910000, 316 173
Show 0BB71C00 2 1
value: ffff78ff
2935 EndFrame: Present(23fefcc, 11f27920) 0
Click 0E910000
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
Show 0BB71C00 2 0
value: ff0079ff
2936 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff7aff
2937 EndFrame: Present(23fefcc, 11f27920) 0
value: ff007bff
2938 EndFrame: Present(23fefcc, 11f27920) 0
SetSize 0E910000, 316 173
value: ffff7cff
2939 EndFrame: Present(23fefcc, 11f27920)SetSize 0E910000, 316 173
 0
value: ff007dff
2940 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff7eff
2941 EndFrame: Present(23fefcc, 11f27920) 0
value: ff007fff
2942 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff80ff
2943 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0081ff
2944 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff82ff
2945 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0083ff
2946 EndFrame: Present(23fefcc, 11f27920) 0
ShowTooltip
SetSize 0BB71C00, 9 22
SetSize 0E910000, 316 173
Show 0BB71C00 2 1
value: ffff84ff
2947 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0085ff
2948 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff86ff
2949 EndFrame: Present(23fefcc, 11f27920) 0
Click 0E910000
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
Show 0BB71C00 2 0
value: ff0087ff
2950 EndFrame: Present(23fefcc, 11f27920) 0
SetSize 0E910000, 316 173
value: ffff88ff
2951 EndFrame: Present(23fefcc, 11f27920) 0
SetSize 0E910000, 316 173
value: ff0089ff
2952 EndFrame: Present(23fefcc, 11f27920) 0
SetSize 0E910000, 316 173
value: ffff8aff
2953 EndFrame: Present(23fefcc, 11f27920) 0
value: ff008bff
2954 EndFrame: Present(23fefcc, 11f27920) 0
ShowTooltip
SetSize 0BB71C00, 9 22
SetSize 0E910000, 316 173
Show 0BB71C00 2 1
value: ffff8cff
2955 EndFrame: Present(23fefcc, 11f27920) 0
Click 0E910000
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
Show 0BB71C00 2 0
value: ff008dff
2956 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff8eff
2957 EndFrame: Present(23fefcc, 11f27920) 0
value: ff008fff
2958 EndFrame: Present(23fefcc, 11f27920) 0
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
value: ffff90ff
2959 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0091ff
2960 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff92ff
2961 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0093ff
2962 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff94ff
2963 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0095ff
2964 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff96ff
2965 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0097ff
2966 EndFrame: Present(23fefcc, 11f27920) 0
ShowTooltip
SetSize 0BB71C00, 9 22
SetSize 0E910000, 316 173
Show 0BB71C00 2 1
value: ffff98ff
2967 EndFrame: Present(23fefcc, 11f27920) 0
value: ff0099ff
2968 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff9aff
2969 EndFrame: Present(23fefcc, 11f27920) 0
Click 0E910000
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
Show 0BB71C00 2 0
value: ff009bff
2970 EndFrame: Present(23fefcc, 11f27920) 0
SetSize 0E910000, 316 173
value: ffff9cff
2971 EndFrame: Present(23fefcc, 11f27920) 0
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
value: ff009dff
2972 EndFrame: Present(23fefcc, 11f27920) 0
value: ffff9eff
2973 EndFrame: Present(23fefcc, 11f27920) 0
ShowTooltip
SetSize 0BB71C00, 9 22
SetSize 0E910000, 316 173
Show 0BB71C00 2 1
value: ff009fff
2974 EndFrame: Present(23fefcc, 11f27920) 0
Click 0E910000
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
Show 0BB71C00 2 0
value: ffffa0ff
2975 EndFrame: Present(23fefcc, 11f27920) 0
value: ff00a1ff
2976 EndFrame: Present(23fefcc, 11f27920) 0
value: ffffa2ff
2977 EndFrame: Present(23fefcc, 11f27920) 0
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
value: ff00a3ff
2978 EndFrame: Present(23fefcc, 11f27920) 0
value: ffffa4ff
2979 EndFrame: Present(23fefcc, 11f27920) 0
value: ff00a5ff
2980 EndFrame: Present(23fefcc, 11f27920) 0
value: ffffa6ff
2981 EndFrame: Present(23fefcc, 11f27920) 0
value: ff00a7ff
2982 EndFrame: Present(23fefcc, 11f27920) 0
value: ffffa8ff
2983 EndFrame: Present(23fefcc, 11f27920) 0
value: ff00a9ff
2984 EndFrame: Present(23fefcc, 11f27920) 0
value: ffffaaff
2985 EndFrame: Present(23fefcc, 11f27920) 0
ShowTooltip
SetSize 0BB71C00, 9 22
SetSize 0E910000, 316 173
Show 0BB71C00 2 1
value: ff00abff
2986 EndFrame: Present(23fefcc, 11f27920) 0
value: ffffacff
2987 EndFrame: Present(23fefcc, 11f27920) 0
value: ff00adff
2988 EndFrame: Present(23fefcc, 11f27920) 0
Click 0E910000
SetSize 0E910000, 316 173
SetSize 0E910000, 316 173
Show 0BB71C00 2 0
value: ffffaeff
2989 EndFrame: Present(23fefcc, 11f27920) 0
SetSize 0E910000, 316 173
value: ff00afff
2990 EndFrame: Present(23fefcc, 11f27920) 0
value: ffffb0ff
2991 EndFrame: Present(23fefcc, 11f27920) 0
Click 0E910000
Click 0E910000
Click 0E910000
Click 0E910000
Show 0E910000 0 0
Show 0E220C00 4 0

last 4 clicks is me clicking on tab after the freeze. The click triggering the freeze should be the one at 2988. Last 2 lines printed when i alt-f4 the browser so it wouldn't suddenly decide to print a hundred lines while i try to copy the console.
Flags: needinfo?(kalviskajaks)
I've worked today to reproduce this on Windows 7 x64 using Jeff's build from comment 218. I managed to get it to reproduce in about 50% of the cases, using the following scenario:

1. Open the build (firefox.exe -console) with a clean profile.
2. Go to https://commons.wikimedia.org/wiki/Category:Gigapixel_images_from_the_Google_Art_Project.
3. Middle click on the first 6 pictures to open them in new tabs (pictures will open on pages with a much smaller preview, so NOT at full size).
4. Start hovering a tab and then try to click on it in sync with the display of the tooltip.
5. Repeat step #4 for 1-2 minutes, then repeat the entire scenario with another clean profile if the issue does not reproduce.

Results: in about 50% of the cases I can get into a state where I've clicked on a tab but it's not selected.

I'm attaching two sets of logs:
- try 1 - I got the issue at around line 406
- try 2 - I got the issue at around line 517
Flags: needinfo?(florin.mezei)
Florin, can you reproduce the issue on computers with different hardware?
Flags: needinfo?(florin.mezei)
I ma(In reply to Jeff Muizelaar [:jrmuizel] from comment #218)
> The new build is up here:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.
> com-854543f58dd8/try-win32/

With this build, managed to reproduce the glitch, then I closed Firefox immediately (should I have done that?), and those were the latest lines printed:

SetSize 18EAF800, 9 22
SetSize 0CC96C00, 316 126
Move 18EAF800, 714 92
Show 18EAF800 2 1
Click 0CC96C00
SetSize 0CC96C00, 316 126
SetSize 0CC96C00, 316 126
Show 18EAF800 2 0
SetSize 0CC96C00, 316 126
SetSize 0CC96C00, 316 126
ShowTooltip
SetSize 18EAF800, 9 22
SetSize 0CC96C00, 316 126
Move 18EAF800, 634 96
Show 18EAF800 2 1
Show 18EAF800 2 0
SetSize 0CC96C00, 316 126
SetSize 0CC96C00, 316 126
SetSize 0CC96C00, 316 126
SetSize 0CC96C00, 316 126
SetSize 0CC96C00, 316 126
SetSize 0CC96C00, 316 126
SetSize 0CC96C00, 316 126
Show 0CC96C00 0 1
Click 0CC96C00
SetSize 0CC96C00, 316 126
SetSize 0CC96C00, 316 126
SetSize 0CC96C00, 316 126
SetSize 0CC96C00, 316 126
SetSize 0CC96C00, 316 126
SetSize 0CC96C00, 316 126
SetSize 0CC96C00, 316 126
SetSize 0CC96C00, 316 126
SetSize 0CC96C00, 316 126
Show 0CC96C00 0 0
SetSize 0CC96C00, 316 132
Show 0B567000 4 0

I never got any line with "EndFrame: Present..."

My graphics settings:

Adapter Description	Intel(R) G33/G31 Express Chipset Family
Adapter Drivers	igdumd64 igdumdx32
Adapter RAM	Unknown
Device ID	0x29c2
Direct2D Enabled	Blocked for your graphics driver version.
DirectWrite Enabled	false (6.2.9200.16571)
Driver Date	9-23-2009
Driver Version	8.15.10.1930
GPU #2 Active	false
GPU Accelerated Windows	0/1 Basic (OMTC) Blocked for your graphics driver version.
Subsys ID	00000000
Vendor ID	0x8086
WebGL Renderer	Blocked for your graphics driver version.
windowLayerManagerRemote	true
AzureCanvasBackend	skia
AzureContentBackend	cairo
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0
Well here is my graphics section if that is of any help.

Adapter Description	NVIDIA GeForce GTX 780
Adapter Drivers	nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Adapter RAM	3072
Asynchronous Pan/Zoom	none
ClearType Parameters	Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 200
Device ID	0x1004
Direct2D Enabled	true
DirectWrite Enabled	true (6.2.9200.16571)
Driver Date	3-13-2015
Driver Version	9.18.13.4788
GPU #2 Active	false
GPU Accelerated Windows	1/1 Direct3D 11 (OMTC)
Subsys ID	00000000
Vendor ID	0x10de
WebGL Renderer	Google Inc. -- ANGLE (NVIDIA GeForce GTX 780 Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote	true
AzureCanvasBackend	direct2d 1.1
AzureContentBackend	direct2d 1.1
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0
I take back what I said about the newer builds not freezing. It turns out the recording software I used to screen capture the console and Firefox simultaneously actually prevents Firefox from freezing.
I haven't been able to reproduce this locally yet. Does this build make it easier to reproduce? http://people.mozilla.org/~jmuizelaar/tab-switch/firefox-36-tooltip-sleep.zip

It adds a sleep at the beginning of the process of showing the tooltip.
This build makes the whole browser microfreeze every 2-3 sec O_o Very noticeable when trying to scroll long pages or lists. Couldn't reproduce the original bug, although i spent only a few minutes trying.
@jrmuizel, if you need more people who can trigger OMTC issues there's a bunch at http://forums.mozillazine.org/viewtopic.php?f=23&t=2915159 (some of whom are probably already in this bug).
(In reply to Jeff Muizelaar [:jrmuizel] from comment #226)
> Florin, can you reproduce the issue on computers with different hardware?

I reproduced this in comment 223 on Windows 7 x64 with GPU: nVIDIA GeForce GT 610.
I tried today on two other machines, the same scenario, but could not reproduce:
- Windows 8 x64 + GPU: Intel HD 4400
- Windows 7 x64 + GPU: AMD Radeon HD 3000

(In reply to Jeff Muizelaar [:jrmuizel] from comment #231)
> I haven't been able to reproduce this locally yet. Does this build make it
> easier to reproduce?
> http://people.mozilla.org/~jmuizelaar/tab-switch/firefox-36-tooltip-sleep.zip
> 
> It adds a sleep at the beginning of the process of showing the tooltip.

I tried this on the same Win 7 with nVIDIA machine where I reproduced the issue, but I could not reproduce the bug with this build (5 tries of the scenario from comment 223). I'd say this build does not in any way make it easier to reproduce the issue.
Flags: needinfo?(florin.mezei)
Attached image tab — 
I can reproduce this in nightly usually once or twice a day. If you need someone to run a test build for a day or so, please ping me.
Can anyone reproduce this problem using the tooltip technique on non-Nvidia hardware?
I have mixed hardware multimonitor (GTX 760 currently 347.88; and Intel 4600 currently 10.18.10.3960) so I can test both with no other variations.

The build from comment #223 is 404ing for me so I tried release ver 37.0.1. Was able to reproduce on Nvidia screen, but not Intel. Something about the nV driver hitting just the right timing to trigger a race condition I guess.
I meant build from comment #218 is 404ing. My bad.
On a hunch... I have been running with desktop composition disabled (Win7 x64) due to some issue with, I think it was OBS, I can't remember the details. Just to see, I turned it back on... I cannot reproduce the tooltip test with desktop composition enabled.

To try to confirm this, I'm going to leave desktop composition on, and if/when I run into that issue again, I'll use compatibility flags to selectively disable composition. Let's see if the issue occurs under this configuration.
I've finally been able to reproduce the tooltip problem on a local nvidia machine :)
So the whole problem is only limited to nV GPUs, or just more frequently?

It makes sense for me at least, I rarely encounter (don't remember if ever) this bug on my laptop which has an AMD GPU, but it's VERY frequent on my desktop (w/ GTX 660) so I have to turn off hardware acceleration to mitigate (not totally solve but much better) it.
I had this freezing issue for several version of Firefox with my AMD graphic card (HD 6850).
But since Firefox 37, it happens often that the repainting is strange when I switch tab. It can be slow, the page is repainted by segments, but if I scroll down the page, it’s repainted instantly.
(In reply to Olivier R. from comment #242)
> I had this freezing issue for several version of Firefox with my AMD graphic
> card (HD 6850).
> But since Firefox 37, it happens often that the repainting is strange when I
> switch tab. It can be slow, the page is repainted by segments, but if I
> scroll down the page, it’s repainted instantly.

You had described perfectly the issue I have with Firefox 37, before it wasn't like that. Now I have developed the habit of clicking on a tab and scrolling a bit to have it refresh. However I have an Nvidia card.
This my have to do with calling SetSize on a window while a Present is happening.
(In reply to Benjamin Peng from comment #241)
> So the whole problem is only limited to nV GPUs, or just more frequently?
> 
> It makes sense for me at least, I rarely encounter (don't remember if ever)
> this bug on my laptop which has an AMD GPU, but it's VERY frequent on my
> desktop (w/ GTX 660) so I have to turn off hardware acceleration to mitigate
> (not totally solve but much better) it.

I'm running AMD GPU (Radeon HD7730) and i'm experiencing this bug. In fact Firefox totally unusable in my case because of this (first appeared on FX37, and even on 38 Beta). And i have to stick with FX36 in the meantime because even with hardware acceleration enabled and layers.offmainthreadcomposition.enabled set to true, i don't experience such problem there.

I submitted the bug report (bug 1151367) with gif attached to show how it looks like from my end (here's the direct link to the gif https://bugzilla.mozilla.org/attachment.cgi?id=8588496).
I'm experiencing this bug also. Windows 7 x64, AMD Radeon HD7570M, Aero enabled.
It's a shame the bug is going to be in the upcoming Fx 38 ESR and therefore will be with its users for another 9 months even if fixed in some of intermediate non-ESR releases. This will probably ruin users' credibility to Firefox even further. Moreover, I doubt that enterprise users will as tolerant as regular users probably are, so many of them will be forced just to switch to another browser, and probably forever.

It probably makes sense for Mozilla to engage MUCH more its programmers to investigating the bug to fix it as soon as possible, and backport the fix to the ESR branch once the bug is fixed.
FWIW, I can reproduce the Nvidia problem pretty reliably now and am starting to gather information on what's going wrong. This seems pretty mysterious and I have no theories as to the cause yet...
Unfortunately, efforts of a SINGLE Mozilla developer are clearly NOT ENOUGH here: we have this deal-breaker bug for over 7 months already and in fact no progress at all.

I believe that at least Mozilla's OMTC implementor(s) should also be involved in investigating this bug.

All other features of Firefox, Firefox-related marketing, and any other efforts to make Firefox popular just don't matter anymore:

in fact, Firefox is literally UNUSABLE due to this bug. Please stop adding new features and focus on fixing existing important bugs like this instead. If a single developer cannot fix the bug, then more developers should be involved.

As for probable reasons of the bug, it looks very probable for me that Firefox's OMTC implementation is buggy itself (tab-title tooltips probably have nothing to do with the bug reason -- their involvement is likely just a side effect) or maybe in conjunction with using Drag & Drop API for tab detaching. So it probably makes sense to find the Firefox version that first introduced the bug (you can do this since you can reproduce the bug already):

find the Firefox build (btw, what exact build it is?) that has OMTC first implemented (but disabled until Fx 33), then enable OMTC in this build, and see if the build is affected by the bug. If it is, then backout (or disable if possible) using Drap & Drop API for tab detaching, and check again if the bug is still here.

Thanks.
windows 7 here, disabling Hardware Acceleration makes the problem go away for me

not sustainable though, for instance this page takes a hit: http://earth.nullschool.net/#current/wind/surface/level/overlay=temp/orthographic=-40.61,70.17,803
It seems that going to Windows Classic (Windows) theme resolves the problem. I agree with Martin, this bug makes Firefox unusable.
I noticed some strange tab rendering when I switched to classic mode:
http://s1.postimg.org/5rlof1xxb/Untitled_picture.png

Maybe this is somehow related. It renders some square angles in background which really looks out of place.
> It seems that going to Windows Classic (Windows) theme resolves the problem.
I have this issue on Win7 + Intel graphics + Classic theme and on Win7 + NVidia + Aero.
Here's a direct copy paste of my previous comment that was posted on bug 1151367 that is closed due to duplicate in case someone from the graphics team didn't see it there before.

The content area (if that's what it's actually called) still shows repainting problem. But the worst part is the address bar area (and the search bar).

I couldn't see what i was typing, so if i made a mistake typing something in that area, i have to select all and then retype it again without seeing what i was typing. The problem from what i can see is it is due to Firefox trying to autocomplete but because of repainting problem it is blocking the view. Of course pictures worth a thousand words so i have uploaded a gif showing the problem.

The gif was also taken from a clean profile and because of that the first word i typed is Mozilla because that word would already be there in bookmark to show you what the problem is. If it was on a live/real profile with hundreds of bookmarks/visited urls history/etc you can imagine every letters being typed would trigger the glitched autocomplete that made you unable to see what you just typed.

Gif Link: https://i.imgur.com/rgs6mFj.gif

(In reply to Vladimir from comment #253)
> It seems that going to Windows Classic (Windows) theme resolves the problem.

Not for me. I'm running Windows Classic Theme and problem persist. I'm on W7 64 and all windows updates are installed. The only workaround that works for me is turning off OMTC or disabling hardware acceleration. But i don't think disabling hardware acceleration is the proper solution and from what i heard the option to disable OMTC will be removed in the near future.
But disabling hardware acceleration alone didn't help me. I cannot see any pattern here.
The only thing which helps 100% is disabling OMTC. But as far as i remember configurations with OMTC off are not supported anymore and can cause crashes or something like that.
Is this problem still just as bad for people on Firefox 39 (current Dev Edition) and Firefox 40 (current Nightly) with e10s off? I barely see this problem anymore myself, so I feel like something got better a while back (possibly while 39 was Nightly), but I never saw this problem with much frequency in the first place so it's hard to judge.
I've filed bug 1157784 about the specific tooltip/nvidia version of this bug to avoid some of the noise of this bug. The work on that bug will continue there.
(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #258)
> Is this problem still just as bad for people on Firefox 39 (current Dev
> Edition) and Firefox 40 (current Nightly) with e10s off? I barely see this
> problem anymore myself, so I feel like something got better a while back
> (possibly while 39 was Nightly), but I never saw this problem with much
> frequency in the first place so it's hard to judge.

I have not experienced this bug in Firefox 40, so far anymore. Switched to beta 38 and triggered bug 5 minutes in..
We are tracking this bug for a while (since we introduced OMTC), we haven't made much progress on this for a while. I don't see the point of us (release manager) tracking it anymore.
status-firefox38: affected → wontfix
tracking-firefox39: + → -
tracking-firefox40: + → -
(In reply to kalviskajaks from comment #261)
> 
> I have not experienced this bug in Firefox 40, so far anymore. Switched to
> beta 38 and triggered bug 5 minutes in..

And just triggered on aurora 39 too. Only nightly seems to be unaffected.
Same here. I filed this bug weeks ago and didn't know about this one: Bug 1140756.

Turning off or on hardware acceleration does not resolve the issue for me and neither does OMTC. It's only happening in Windows 7 and not XP so I figure it has to be graphics-related.
(In reply to comment #264)
This bug 1067470 has nothing to do with desktop.
Your bug 1140756 looks like a separate different issue.
(In reply to Marat Tanalin | tanalin.com from comment #265)
> (In reply to comment #264)
> This bug 1067470 has nothing to do with desktop.
> Your bug 1140756 looks like a separate different issue.

Could be separate but appears related as it occurs primarily when switching tabs and is a repainting issue. Interestingly, the problem began at the same time, around v33 or 34. 31ESR is unaffected.
I can confirm that 39.0a2 (2015-05-10) works OK. Also I can confirm that switching off Windows Aero does not help.
I'm using Firefox Nightly (40.0a1) (instead of previously used Dev. Edition 39.0a2 which was horrible as for this bug) for a week (with e10s disabled) and have encountered the bug twice:

* one with tab in tabbar (exactly as originally reported), and
* another one was repainting issue in tab contents (new-tab tiles area rendered partially).

So the bug is NOT fixed, just reproduces much more rarely.

Now I've enabled e10s and will observe further.
Thats really uncool ... Maybe it's fixed in V99 :P

In other browsers it works.
Depends on: 1157784
I've put up a build that has what I believe is a fix to the tooltip issue at:
http://people.mozilla.org/~jmuizelaar/firefox-36.0-tabswitch-fixed.en-US.win32.zip

I'd encourage everyone to try it out.
Here's a FF40 build with a similar fix:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-53dc8fbaa2b6/try-win32/

I'm very interested in the problem people can reproduce with this build.
Flags: needinfo?(bas)
FWIW, tried both of those test builds and neither corrected the problem as described in bug 1140756. In fact, the 36 build was unusable it was so bad. I'm assuming then that it is separate from this bug if they fix the issues regarding this one. 

Other users are experiencing the desktop glitch as I am so hopefully developers will take a look at that as well:

http://www.reddit.com/r/firefox/comments/34qlmz/sometimes_when_changing_tabs_my_desktop_icons/
Both of the test builds fix the issue for me. Tab switching is bugfree and very smooth. Marty in your bug 1140756 you write that the issue occurs with both OMTC on and off, so it must be an unrelated bug, because this one was caused by OMTC and did not occur with OMTC switched off.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #272)
> Here's a FF40 build with a similar fix:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.
> com-53dc8fbaa2b6/try-win32/
> 
> I'm very interested in the problem people can reproduce with this build.

I've tried to reproduce the problem using this try build, on the same Windows 7 x64 machine where I was able to see it before. I used the scenario from comment 223 multiple times with new profiles, but did NOT manage to reproduce the issue at all.
Firefox 38 is horrid. It often freezes and sometimes repainting is slow and appears section by section.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #272)
> Here's a FF40 build with a similar fix:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.
> com-53dc8fbaa2b6/try-win32/
> 
> I'm very interested in the problem people can reproduce with this build.

At the moment, no freeze, no segmentation while repainting.
But characters seem less smooth than in Firefox 38 and scrolling seems slower (not sure).
(In reply to Jeff Muizelaar [:jrmuizel] from comment #272)
> Here's a FF40 build with a similar fix:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.
> com-53dc8fbaa2b6/try-win32/
> 
> I'm very interested in the problem people can reproduce with this build.

I just tested running your FX40 build with clean profile and it still shows flickering/repainting problem? for me. I've captured and uploaded it to GFYCat at https://gfycat.com/LazyGenerousAustralianshelduck

Also the same problem i described before (comment #255) still exist on your FX40 build.
Today's build is giving me constantly this bug.

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015-05-15-08-47-17-mozilla-central/

Anyone else experiencing the same?
Aditya your bug looks different, than this one, you should file a new bug.
(In reply to kalviskajaks from comment #279)
> Aditya your bug looks different, than this one, you should file a new bug.

I made one and it got closed (bug #1151367) because it's a duplicate for this bug (see my previous comment #255, i stated it there before) and that's why i'm posting here.
I've been getting this bug through the past couple of versions of Firefox and am now seeing it regularly in 38.  The window fails to repaint, although some active elements will repaint if you run the mouse over them.

You can see here I clicked on tab 3 (Twitter) from tab 2 (Harper's).  At first even the tabs at the top didn't even repaint, but as I moved the mouse to get a screenshot they finally did.  You can see where some of the Twitter page (yes, I follow Raffi) was repainted but large sections of the window were not.

http://crywalt.com/firefox_repaint_problem.png

This is happening, as near as I can tell, randomly, but frequently.  It's making FF unusable.  I'd hoped the newest update would help but I no.  I see this is a very long-standing issue.

I'm running FF38 under Windows 7 Ultimate 32-bit.
(In reply to Ray Satiro from comment #84)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #82)
> > Can anyone reproduce this issue on hardware other than Nvidia?
> 
> I filed dupe bug #1130437 and I'm also Intel HD3000 Win 7 x64. Note I'm
> using x64 builds. The bug includes a video showing what happens and as noted
> was reproducible with HWA on or off. Since I filed that bug it has not
> happened a single time. I think maybe there is something I was doing that
> was CPU intensive, or something, that made it easier for the bug to show
> itself at that time. Also, since filing that bug I've disabled OMTC due to
> another bug so that may be why I haven't encountered it.
> 
> Just now I tried for ten minutes in a clean profile to reproduce and I
> can't. Sorry but I can't devote the cumulative amount of time that would be
> required in my case to create a regression window. It would probably be
> hours.

FYI Jeff I haven't had this issue happen to me since my report back in February. I've used Nightly regularly throughout.
FWIW I've got an Nvidia card here.
I reported one of the earliest bugs (Bug 1065463) later duplicated to this bug, and the fix for bug 1157784 (split from this at comment 259) seems to have fixed things for me. After the fix materialized in Aurora 41 two days ago, I have not seen a single incident of tab freezing. 

The fix from bug 1157784 is already in nightly, aurora and beta, and will be in the 38.0.5 release, too. (and it might even be uplifted to esr38.)

I wonder if this bug should be marked fixed.
Let's call it a duplicate of bug 1157784
Status: NEW → RESOLVED
Closed: 10 years ago → 9 years ago
Resolution: --- → DUPLICATE
If anyone is still seeing issues, please file a new bug and mention it here.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #286)
> If anyone is still seeing issues, please file a new bug and mention it here.

With the builds that have this fixed: i.e 38.0.5, 39, 40, 41
and patch will also be uplifted to ESR branch



Thank you very much Jeff Muizelaar [:jrmuizel] for fixing this long standing issue! \o/
No longer blocks: 1130362
Severity: critical → major
Status: RESOLVED → VERIFIED
status-firefox38.0.5: wontfix → verified
status-firefox39: affected → verified
status-firefox40: affected → verified
status-firefox41: affected → verified
status-firefox-esr38: --- → verified
This should be released now as FF 38.0.5
Great, Jeff. When will it be applied to ESR branch (38.0.1 is currently the latest ESR available)?

By the way, is it OK that Firefox 31.7.0esr does not automatically update to 38.0.1esr and says that Firefox version is already up-to-date in the About window? Maybe updating ESR from v31 to v38 has been delayed by Mozilla exactly until this bug is fixed?
(In reply to Marat Tanalin | tanalin.com from comment #290)
> Great, Jeff. When will it be applied to ESR branch (38.0.1 is currently the
> latest ESR available)?
It will be part of ESR 38.1.0 (June 30th).

> By the way, is it OK that Firefox 31.7.0esr does not automatically update to
> 38.0.1esr and says that Firefox version is already up-to-date in the About
> window? Maybe updating ESR from v31 to v38 has been delayed by Mozilla
> exactly until this bug is fixed?
This is an unrelated question. Please ask it on the enterprise ESR (or send me an email directly).
It seems most reporters here are Windows users.  I have experienced the same lagging under FF38 on Ubuntu.  There's no Direct2d, at al.  But when set layers.acceleration.disabled to be "true" in about:config, the problem went away.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #289)
> This should be released now as FF 38.0.5

[Preface to comments - I am not a developer, just an experienced user; and a bugzilla newbie]

I have just tested this build on an XP platform which has been suffering the symptoms of this bug ever since FF33.x (indeed I reverted to FF32.0.2 many times and can confirm that I never had this problem on this or prior releases).

Having read the release notes, my hopes were high. Unfortunately I can report that the tab re-painting problem is still there.

Thanks to those who are working on this really annoying bug.

Whilst my XP platform usage might be a little unusual (? I typically run 15 windows with a total of approx 300 tabs), I have also witnessed the same problem (albeit much less frequently) on a Win7 machine with plenty of RAM.

As each new build since FF since 33.x I have been hoping for a resolution.  Actually since about 35.x it has become actually quite chronic on this XP platform.  That is, within 30 minutes of launch the browser will become effectively unusable.  A FF restart will clear the problem for a period of time (I normally restart with the same tab set).

When I first encountered the problem in Nov 2014 the XP machine was physical.  Since then, I virtualized it with VMware which is running on completely different hardware (notably graphics) and under Win8.1.  I can positively state that FF (mis)behaviour has remained the same.

I suspect that I could reduce and maybe eliminate the symptoms by slimming down my tab usage, and also creating a new FF profile, however I would prefer to keep these characteristics until the bug is truly fixed.  I am now doing most of my browsing on my W7 and W8.1 systems to avoid the total inconvenience caused by this bug.
Bill, that sounds like a different bug, probably related to high memory usage (300 tabs is a lot for Firefox on a 32-bit OS). I'd suggest checking the memory usage in Task Manager when this happens, and about:memory will have more details on where the memory is going (the information is pretty technical though). It might be worth filing a new bug for this, especially since you say it's gotten worse since 32!
Can anyone confirm this bug is now affecting Thunderbird 38.0.1 (release)? I'm getting the same symptoms (delayed painting when switching tabs or selecting different folders, etc) of this bug now in Thunderbird.
Yes. I can confirm it happens on TB 38.0.1 sometimes when I select another folder. But it doesn’t happen often.
I don’t use tabs, so I can’t confirm for this case.
Thanks for confirmation. I use the Lightning calendar extension and switching to this tab in Thunderbird will sometimes not paint anything at all, and (very oddly) some calendar number days will paint when you hover over them. I've confirmed that disabling HW acceleration (in Thunderbird) fixes the issue, but as someone else mentioned above, that's not a sustainable fix (but at least that's an option until it gets fixed.)

I'm not too familiar with Bugzilla's implementation, can this now be worked on as a "Thunderbird" issue or does a new bug need to be filed somewhere else?
I have an update. Disabling my gpu's (XFX R9 280) overclock seemed to have solved the issue in Thunderbird. This could explain the somewhat "rarity" of this bug overall affecting both Firefox and Thunderbird, considering the small number of people who overclock their gpu's to max core and memory clocks (at least for me as I did and ran fine with no artifacting whatsoever, even spending hours running Heaven benchmarks at ultra settings at 1200p. But, things changed when I bought a second monitor and ran into some curious trouble and thus connected the dots with this investigation.)

I'm looking for some corroboration here. How many of you previously had this bug in Firefox and also overclocked your gpu -- even at mildly-higher clocks?
I didn’t overclock my GPU.
(In reply to Bob Barker from comment #298)
I did have this bug previously, and I do have both of my 7970s overclocked.
Forget it, after further testing, this bug is unrelated to gpu overclocking.
Unsure if this is related to WM_SETTEXT so I'm posting here and not on that bug. I followed that issue and that patch did not resolve the painting issues for me even after refreshing Firefox.  I've attached a screenshot of the painting issues on a new tab which was not repainted after switching from about:addons.  It only happens on this computer and I've had similar problems since at least FF37.

Firefox 39.0 (20150630154324)
Adapter Description	Intel(R) HD Graphics
Adapter Drivers	igdumd32 igd10umd32 igd10umd32
Adapter RAM	Unknown
Asynchronous Pan/Zoom	none
Device ID	0x0152
Direct2D Enabled	true
DirectWrite Enabled	true (6.2.9200.17292)
Driver Date	2-1-2012
Driver Version	8.15.10.2639

Adblock Plus	2.6.9.1-signed
HTTPS-Everywhere	5.0.5
After a few days of using, this bug appears fixed for me as of TB 38.1.0, released on 9 July. No mention of delayed painting issues in the release notes: https://www.mozilla.org/en-US/thunderbird/38.1.0/releasenotes/

My settings again for reference:
hw acceleration on
gpu overclock disabled
TT DeepDark theme
all plugins disabled/set to "never activate"
the flag "media.peerconnection.enabled" set to "false" (to prevent external IP leakage)
Still the same problem here on Windows 10 with Fx 42.
Sometimes Firefox will be rendered white, sometimes black, sometimes only partly...
I experience this issue in Firefox for Ubuntu, version 45.0.1. Disabling hardware acceleration doesn't resolve it.
(In reply to EmuAGR from comment #305)
> I experience this issue in Firefox for Ubuntu, version 45.0.1. Disabling
> hardware acceleration doesn't resolve it.
status-firefox34: wontfix → ?
tracking-e10s: --- → ?
Flags: needinfo?(mtanalin)
Flags: needinfo?(mtanalin) → needinfo?(jmuizelaar)
(In reply to EmuAGR from comment #305)
> I experience this issue in Firefox for Ubuntu, version 45.0.1. Disabling
> hardware acceleration doesn't resolve it.

Don't think that's the same bug, this one was explicitly dealing with Windows API.
Could you open another bug for your issue?  CC me on it, and make sure we have your about:support.
Flags: needinfo?(jmuizelaar)
What chipset are you running on ?

(In reply to EmuAGR from comment #305)
> I experience this issue in Firefox for Ubuntu, version 45.0.1. Disabling
> hardware acceleration doesn't resolve it.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: